Coding styles for C-family languages

[Chaotic42]

I was looking around online about various coding styles since I'm actually taking a proper programming class instead of trying to patch together various code from various sites to get something working. I don't really have a style, so I figured I'd read up on what people thought was best and why. I'm finding some interesting debates, so I thought I'd ask you guys if there were any specific idioms (I guess that's the right word) that you all use on C, C++, C#, etc.

The one thing that I found interesting is that people use spaces for indentation instead of tabs. Since I thought this was the entire point of the tab key and since it's customizable in virtually every editor, it seems like a no-brainer to use the tab key. What's your take?

Also, any thoughts on "Camel Case" vs using tons of underscores? I really like the underscore thing for variables but tend to use Camel Case for objects, since that's how most of the code samples I've seen do it.

What are your favorite idioms and what other idioms really bug you?

 

[Markbnj]

The one thing that I found interesting is that people use spaces for indentation instead of tabs. Since I thought this was the entire point of the tab key and since it's customizable in virtually every editor, it seems like a no-brainer to use the tab key. What's your take?

An old, old debate . Theoretically everyone should use tabs, and then you could set your local indent to what you want it to be. In practice, for whatever reason, it rarely works that way, and instead you end up with your code structure getting mangled on different machines. People who prefer all spaces (me, for one) would rather just have a set format based on the character width.

 

[mv2devnull]

Herb Sutter has published an opinion or two about style and idioms. You may or may not disagree with him.

Personally, I don't care.

 

[Merad]

Main main rules are:

Class/struct and function names ShouldBeLikeThis
Prefix virtual function names with a V
Macros and preprocessor symbols SHOULD_BE_LIKE_THIS
Variable names shouldBeLikeThis
Prefix member variables with m_
Prefix global variables with g_
Prefix static variables with s_
Prefix constants and enum values with k_
Other than the above do not use hungarian
Braces always go on a new line
Always use braces, even when optional
All documentation should be Doxygen compatible
Try to keep things to < 80 characters per line

That said you must be flexible. Different languages have different "standard" styles. If I'm writing Java, I write java style. And unless you're the boss, in the real world the odds of you getting everyone you work with to write in your preferred style is just a hair above 0.

The one thing that I found interesting is that people use spaces for indentation instead of tabs. Since I thought this was the entire point of the tab key and since it's customizable in virtually every editor, it seems like a no-brainer to use the tab key. What's your take?

As already said, it just doesn't work out that way. Never really bothered to figure out why. I use 2 spaces per tab.

Also, any thoughts on "Camel Case" vs using tons of underscores? I really like the underscore thing for variables but tend to use Camel Case for objects, since that's how most of the code samples I've seen do it.

Waste_of_space. And it's actually more difficult to read than camelCase IMO.

What are your favorite idioms and what other idioms really bug you?

The one that irks me most is pointer and reference notation. The * or & is part of the type. There's no logical reason to separate it from the the rest of the type name (eg use int* instead of int *). But that's a losing battle.

 

[iCyborg]

The one thing that I found interesting is that people use spaces for indentation instead of tabs. Since I thought this was the entire point of the tab key and since it's customizable in virtually every editor, it seems like a no-brainer to use the tab key. What's your take?

It might not be tab key per se. Most of modern editors support "replace tab with spaces". You can use tabs for your work, but it will not affect others or other editors. At work, I'm actually required to do this. I have 0 problems with this, and it makes sense if you're not the only one working on something.

I've already expressed my opinion on Camel Case etc. here, maybe more than once...

 

[douglasb]

camelCase for instance variables. CAPITALS_WITH_UNDERSCORES for constants. UpperCamelCase for object properties and methods.

Lots of my coworkers use Hungarian notation but IMO, it is a dated practice and pretty much worthless with modern IDEs. Not to mention, it makes the code harder to read IMO.

 

[degibson]

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Although, as always, style consistency is pretty important too.

 

[Chaotic42]

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Although, as always, style consistency is pretty important too.

Wow, Ice Weasel rendered that beautifully. it's just a block of text with no whitespace.

Wky 'k' for consts and enums? Thanks for the replies, everyone.

 

[Net]

generally you should follow the style of the language that you are working in and be consistent.

there are a lot of great books about writing clean code that focus on style.

more general see http://en.wikipedia.org/wiki/Coding_conventions

java http://www.oracle.com/technetwork/java/codeconv-138413.html
C# http://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx
...

 

[degibson]

Wky 'k' for consts and enums? Thanks for the replies, everyone.

Well, enums are compile-time constants, so it does sorta follow that enums and compile-time constants would have a similar style suggestion.

As for why kSomething is used instead of SOMETHING for compile-time constants, it's to differentiate from MACROS.
"Until January 2009, the style was to name enum values like macros. This caused problems with name collisions between enum values and macros"

 

[Fallen Kell]

I would read some of this article, and of course grab the code it is talking about and take a look. The author has some really good points about the code style used.

http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code

 

[Staples]

I use

Tabs
camelCase for variables
Classes, Namespaces and Methods start with capital letters

I rarely use underscores although some languages like Python seem to prefer them.

 

[Chaotic42]

What about project organization in general? I've been working on a program which has a class that is getting kind of large. I'm splitting it up into multiple files:

ClassName.Function1.cs
ClassName.Function2.cs

and so forth. Is this good tradecraft? It seems easier to work on than just having a single class file with several hundred lines of code.

 

[Scooby Doo]

I guess it would depend on the size of the functions. No sense in having tons of little 5 line functions in seperate files, it would make visual scanning annoying.

 

[Markbnj]

What about project organization in general? I've been working on a program which has a class that is getting kind of large. I'm splitting it up into multiple files:

ClassName.Function1.cs
ClassName.Function2.cs

and so forth. Is this good tradecraft? It seems easier to work on than just having a single class file with several hundred lines of code.

I assume this is c#, and you're using partial classes? They are a strange feature, and I'm not sure I like seeing them used this way. They're sort of a hack, imo, to allow the combination of generated and edited code in one class at compile-time, which was necessary originally for ASP.NET and then for WPF/XAML, etc.

I guess there's nothing really wrong with decomposing this way, although if one class is really getting that larger my inclination would be to look at refactoring it, rather than splitting it up. Perhaps it is doing the work of several classes that can be composed.

 

[Train]

What about project organization in general? I've been working on a program which has a class that is getting kind of large. I'm splitting it up into multiple files:

ClassName.Function1.cs
ClassName.Function2.cs

and so forth. Is this good tradecraft? It seems easier to work on than just having a single class file with several hundred lines of code.

I would take that naming convention as a code smell telling you that your functions are way too large.

And then your classes are probably too large as well.

 

[Munashiimaru]

Main main rules are:

Prefix member variables with m_
Prefix global variables with g_
Prefix static variables with s_
Prefix constants and enum values with k_

Disclaimer: Most of the below is in regards to java/c# (netbeans/eclipse/VS). Especially with naming anything that's more loosely typed, it is going to be a different beast. If you're doing something like windows API calls in C++, you're going to definitely want something like hungarian notation.

Depending on the IDE doing what's quoted tends to just be extra clutter. Most modern languages/IDEs it's very easy to distinguish these things with a mouseover. Only time I use any sort of type notation (hungarian is what I use) in names is when I'm declaring stuff in a GUI/webpage and then dealing with it in another class where it becomes an immense convience to have all checkboxes prefixed with ckb (or whatever you define in your stands) (especially in VS not so much in Eclipse but still somewhat good).

My personal coding standards are: Never abbreivate unless it's a business abbreviation (any abbreviations used should be defined in the requirements documention ideally). Put some thought into your function/class/variable names. If you're using single letters (besides for indexes) or names like temp, 99% of the time there's a better name that can be used. Declare variables in the highest part of the scope that it's used. You don't want variables that are floating around; it then has to be decyphered where and only where it gets used by later programmers. In the same vein, avoid reusing variable names; it almost never saves you any real memory/performance due to how garbage collection works and makes a place that needs to be decyphered like having variables in a scope where they're useless. For example, a string is immutable. Using the same temp variable 30 times over doesn't save you any processing or memory. Reistantiating objects at best generally just leads to a tiny amount of memory available to be garbages collected microseconds sooner (but it probably won't be).

Always use small functions/classes (prevents ginormous naming and immensely helps readbility). I'm a little looser than each function doing strictly one thing, but never more than one plus other function calls. Rule of thumb is functions shouldn't be much more than a page height and classes no more than 2-3, but that's a very loose rule.

Vertical white space is an asset you spend to get readibility. Using it to seperate logical pieces helps a ton with readibility, but if you use too much it makes it hard to take in what's going on in the overall flow of code.

Comment all classes/functions/global variables with autodocumenting code (/** in eclipse and /// in VS). That way people can get a description of these things with a mouse over. Comment any underlying code that's using some funky logic to get things done (in a perfect world this wouldn't happen but it does especially when dealing with code out of your control). Everything else should be explained by using good names/keeping classes/functions small.

Sticking to the above makes it so that a lot of extra clutter other people tend to add becomes obsolete.

On tabs, when I was using notepad to write java I used spaces. On any decent, IDE you should be using tabs. Basically if tabbing is likely to be a mess don't use them otherwise do.

I never use underscore. It's just added clutter especially for classes/variables where camel/pascal case is the norm. I usually just all cap constants without underscores, but that's really a debatable thing to do.

The number one rule though is to follow the coding standards of the project you're working on even if it's different from what you like. Don't just say screw it I'm doing my own thing whether it fits in or not.