Take the 2-minute tour ×

For those of us that have programmed enough I’m sure we have come across many different flavours of coding standards that you can use when it comes to programming.


You might derive your coding standards for the current company you work for or from the original author of the code you’re working on. Coding styles are often used for specific program languages and some styles in one coding language might not be considered appropriate for others. Of course some coding standards can be applied across many different program languages.

Thank you for your time.

EDIT: As we know there are many related articles on this subject, but C# Coding standard / Best practices in SO has some very useful links in there which is worth a visit. (Check out the 2 links on .NET/C# guidelines by ESV - Accepted Answer)

share|improve this question
Not to mention that it's been asked before, see the 'related questions' column to the right. I can count three. –  George Stocker Feb 20 '09 at 13:44
possible duplicate of C# Coding standard / Best practices –  BalusC Nov 17 '11 at 1:44

20 Answers 20

up vote 12 down vote accepted

Google has a posted style guide for C++ here which I consult sometimes. Just reading through the explanations and reasoning, despite whether you end up agreeing with some of the styles or not, may teach you some things you might not have thought about.

share|improve this answer
And I just hope it doesn't spread: groups.google.ch/group/comp.lang.c++.moderated/browse_frm/… –  Anonymous Feb 20 '09 at 9:51
Google's style guide is great, but they advise against exceptions, for interoperability reasons. People should note that this is specific to Google and they need to reevaluate this point based on their situation. –  Nikhil Mar 7 '09 at 1:21
of course, you don't have to take every part of the standard as if it was writ in stone. Use what makes sense to your team. –  gbjbaanb Apr 15 '09 at 18:26

My best advice regarding coding standards: don't let them get in the way when trying to get work done.

A big bureaucracy might actually hinder progress in projects instead of helping to achieve better team work. When people complain about not following coding standards instead of the actual quality of the code, then it is too much regulation.

Other than that, pick one from the many suggestions and try to stick with it for as long as possible to build a code base following a single standard that you are used to.

share|improve this answer

Coding standards are good, but coding standards written from scratch in which the company reinvents the wheel, or coding standards imposed by a single "prophet", can be worse than having no coding standards at all.

This means:

  • Coding standards should be discussed and agreed upon.
  • The coding standards document should include the reasons behind each rule.
  • Coding standards should be at least partially based on reliable sources.

The sources I know of for the languages in your tags are:

  • For C++: The book C++ Coding Standards by Sutter/Alexandrescu.
  • For C#: 4 or 5 PDF's I found googling for C# Coding Standards :)
share|improve this answer

Adam Cogan has a great set of rules on his web site. There are coding guidelines, but there is much more there also.

Adam Cogan's Rules to Better...

share|improve this answer

Coding standards are great. We've been using Lance Hunt's C# Coding Standards for .NET almost without modifications

share|improve this answer

If you are maintaining code that continue to use the same standard as the original code was developed in (there is nothing worse then trying to debug a problem when the code looks all higgildy piggeldy)

share|improve this answer
I always think this should be the first (and sometimes only ;) ) rule for a coding standard. It definitely should override all other rules. –  gbjbaanb Apr 15 '09 at 18:29

Some comment to the post suggesting looking at the Google C++ guidelines. Detailed discussion about some aspects of these guidelines are posted at comp.lang.c++.moderated.

Some weird or controversial points include:


As if assertions were a viable alternative... Assertions are usually for programming errors and situations that should never happen, while exceptions can happen (are somewhat anticipated) in the execution flow.

Reference Arguments: All parameters passed by reference must be labeled const. ... In fact it is a very strong convention that input arguments are values or const references while output arguments are pointers.

No comment, about weasel phrase a very strong convention.

Doing Work in Constructors: Do only trivial initialization in a constructor. If at all possible, use an Init() method for non-trivial initialization.  ... If your object requires non-trivial initialization, consider having an explicit Init() method and/or adding a member flag that indicates whether the object was successfully initialized.

Yes... 2-phase init to make things simpler... What if I have const fields? This rule is probably the effect of attitude towards exceptions.

Use streams only for logging

Which streams? IOStreams, standard C streams, other?

On one hand they advise to use macros only in exceptional situations, while they recommend using DISALLOW_COPY_AND_ASSIGN to prohibit copy/assign. They could have advised the approach with special class (like in Boost)

Do not overload operators except in rare, special circumstances.

What about assignment, or arithmetic operators for numeric calculations, etc?

Default parameters are more difficult to maintain because copy-and- paste from previous code may not reveal all the parameters. Copy-and- pasting of code segments can cause major problems when the default arguments are not appropriate for the new code.

The what? Copy/paste from previous code?

Remember that reading any of the guidelines can introduce a bias to your way of thinking. And sometimes it won't be beneficial for you or your code. I agree with some other posts advising reading good books by good authors beforehand. When you have sufficient amount of knowledge, then you are able to look at the guidelines and find good and weak points easily, without creating a mess in your brain ;)

share|improve this answer

If you plan to introduce a code-formatting standard to an existing programming team, get input from each member of the team so they'll have "buy in" and be more likely to write code to that standard.

Programming styles are as difficult to change as habits, and you'll have to accept that some people won't make their code 100% compliant 100% of the time. It would be worth your time to find (or write your own) pretty-printer program and periodically run all your code through it to enforce consistency. (I always felt uneasy when manually checking in source code changes that only consisted of formatting corrections for other peoples' code; I worried that others would label me a nitpicker.)

share|improve this answer

Having asked this question. I found that the accepted answer proved to be sufficient for my needs.

However, I realise that this is not a 'one-size-fits-all' scenario, so there is a large quantity of information within the thread that you may find more or less useful. Weel worth a read!

share|improve this answer

For Java and other C-family languages I recommend Sofware Monkey's coding standards (of course, since they're mine).

In general, keep them simple, and provide examples and justification for every requirement.

share|improve this answer

What's in the standard doesn't really matter all that much. What matters is that you have one, and that your developers follow it.

share|improve this answer

It doesn't quite answer the question, but it's worth a mention...

I read Steve McConnell's Code Complete. Whilst it doesn't give you a pre-baked set of coding standards it does set out a lot of good arguments for the various approaches. It'll make you think about things you'd not thought of before.

It changed my little world for the better.

share|improve this answer

Coding standards themselves are great and all, but what I think is much, much, MUCH more important is keeping with the style of whatever code you're maintaining. I've seen people add a function to some class written one way and forcing their coding standard on just that function. It's inconsistent, it sticks out, and, in my opinion, it makes it harder to enjoy the class "as a whole".

Whenever you're maintaining code, look at the code around it. See what the style is. K&R braces? Capital Camel Case methods? Hungarian? Double-line comment blocks between every function? Whatever it is, you should do it too in that specific area.

Before I leave, one thing I'd like to note that's related - naming files. I'm mainly a C++ guy, so this may not apply to whatever else, but basically it goes _.h or .cpp. So, Foo::Bar would be in Foo_Bar.h. Common things (i.e. a precompiled header) for the Foo namespace would be in Foo_common.h (note the lowercase common). Of course, that's a taste thing, but everybody who has worked with this has come out in favor of this.

share|improve this answer

i think Code Craft - The Practice of Writing Excellent Code pretty much sums it all up

share|improve this answer

Very popular are Ellemtel rules for C++.

share|improve this answer
I like it, one of the firsts recommendations document. –  Ismael Feb 20 '09 at 11:28
yeah right - try printing it out, then get a colleague to test you on rules at random. I guarantee you'll never score 100%, and if you cannot do that, then your code will never conform to the standard, and if your code never conforms.. then what's the point of having a standard in the first place! –  gbjbaanb Apr 15 '09 at 18:25

The answers here a pretty complete, thus I am not pointing to another coding standard document. However, once you decided to stick to one style you should use an automated coding style enforcer throughout your team.

For Java there is checkstyle and for .NET Microsoft Style Cop.

Here is a similar discussion on Stackoverflow: C# Coding standard / Best practices

share|improve this answer

Camel and pascal casing alone solves a lot of coding standard problems

share|improve this answer

Your Answer


