Coding standards are common in any software development organization, but how important are they to follow? I can understand the need for some consistency, but when dealing with simple things like the position of braces, line length, etc., I'm not sure excessively strict standards contribute much to software development.

Isn't it more important that your code is readable, not that it conforms to a predefined standard? It seems they're more like... guidelines anyway.

9 Answers 9


Asking everyone to 100% adhere to the same standard code formatting guideline is like asking everyone to collaborate separately on writing a 100 page paper with the same writing style.

Hopefully everyone will write the paper in English (or same language), but different styles will be apparent. Some will write it well, others not. Some will use contractions, some will spell the words out fully (example: it's verus it is). Etc.

I think you touched on the most important points:

  1. It's a guideline
  2. Readability

If you want the code to adhere to the same formatting, like a paper to be in the same writing style, it'll need editing and revising. The code will need to be cleaned up, reviewed, re-factored, etc.

I've never been in a shop where I was completely happy with another developer's coding style or formatting (at minimal because it's not exactly like mine). But I'll be content if I can read/understand it and if it's consistent. Everything else is the sugar on the syntactic sugar.

So to answer your question: somewhat important, but it's certainly not the end of the world if they don't.

  • 3
    Especially #2: Readability. Sometimes a specific bit of code can be made more readable by deviating from the guideline. Commented Sep 14, 2010 at 10:01
  • Thanks to todays IDEs you can get closer to 100% if you reformat the code based on a template with every save operation. Eclipse does that quite nicely.
    – Markus
    Commented Nov 20, 2013 at 13:36
  • 1
    @Markus this works until someone wants to use another IDE or editor. I prefer doing it in a pre-commit hook to give more freedom to the developers. Commented Apr 7, 2017 at 11:39
  • Fair point @GustavKarlsson, in this way you centralize the formatting and create a single point of change in case the "standard" changes. As a workaround (with more effort involved) you could always write an additional template for the new IDE.
    – Markus
    Commented Apr 10, 2017 at 7:56

For formatting standards, I follow what everybody else is doing. If they are using PascalCase for everything, then I use PascalCase. If they use _camelCase, then I use _camelCase. Why? Because it limits the amount of reformatting I do, and limits what others have to do to make it "look good". Formatting standards are usually there to make things easy for everybody.


At my current job, one of my first tasks was to come up with a coding standard for our development group.

My first effort was about sixty pages long (it incorporated much of the Framework Guidelines from Microsoft). I was asked to pare it down, and my next effort was ten pages long, utilizing ideas from a variety of good sources. I was asked to pare it down again, and finally got it down to three or four pages, I think.

It was never adopted.

Why? Because I work with a lot of really smart people, who already follow a sensible coding standard instinctively.

For my part, I follow generally-accepted guidelines from Microsoft, and emulate the commonly-used styles of others (Javascript and jQuery are formatted differently from C#, even though they are both curly-brace languages). I also break the rules from time to time, when doing so will make the code more readable.

  • Why did you write your own coding standard when so many exist out there, and are actually standard to the language/framework used? Commented Nov 19, 2013 at 18:58
  • 2
    It was never adopted - tadaa, and there was the statement I was looking for while browsing the answers. That's the whole point of it: the more people and the higher both complexity and arbitrariness of the rules, the less likely they will be ever adopted by even a majority of the team. Unless it's not enforced somehow, like Visual Studio or the Go language do, developers tend to follow their own minds. I am waiting for nearly 10 years now for the IDE that separates code content from code styling.
    – JensG
    Commented Nov 20, 2013 at 12:22

If you use and IDE that does the basics of this for you (Visual Studio for example), let the IDE do it's thing and whatever seems to still be hard to look at you modify as long as you still let the IDE do it's thing or the next person that auto-formats it is just going to kill it anyway.

What is most readable to one person will not be for all people.

If you are not using this sort of IDE get one. Even thinking about this for more than 10 minutes is a waste of resources IMHO.

  • 4
    I have to disagree. I find nothing more irritating than an IDE that changes the formatting on its own. Why should I be letting it modify my code without my consent? It cuts out a decent portion of control that I like to have over my work. Commented Sep 11, 2010 at 4:45
  • Bill, are you talking about the drag-n-drop naming conventions that the IDE generates such as TextBox01? Or do you mean a Visual Studio plugin like Resharper?
    – spong
    Commented Sep 11, 2010 at 18:24
  • derek - yes, that is annoying, but the time it saves me from not having to pay attention to it 90% of the time is worth the 10% of the time I have to wrestle it.
    – Bill
    Commented Sep 11, 2010 at 18:57
  • sun - I meant formatting only in this case. I would be ok with the default control names on drop only if it were exceedingly obvious what was going on. in many forms that falls apart after the second control. I am not a huge resharper fan, but when I use it I don't try and correct what it generates much either. Don't fight your toolset when you don't have to.
    – Bill
    Commented Sep 11, 2010 at 19:01
  • There can be multiple IDEs in the same team - E.g. Eclipse and IDEA for Java. It would take a little effort to setup code formatting in the form of config files - but it's worth it.
    – talonx
    Commented Sep 14, 2010 at 11:17

I think there's an unmentioned benefit in helping to quickly understand code. The more similar that code formatting is across a project and all developers, the easier (and more subconsciously) you'll be able to work with the code.

I've had junior developers come to me after trying to deal with even simple bugs for an extended period of time. After taking a few minutes to apply our code format with them, they were quickly able to see the bug that they had missed before.

While readability is definitely important. If your code format standards are well thought out, and are properly used, you may find that you can go beyond just being able to read the code, and to being able to understand the code even quicker.

One set of guidelines I use when developing or updating our coding formats is the Gestalt Principles of Grouping - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

As a direct result/example our code formatting requires that any block code (if, switch, etc.) has the open brace on the next line, so that it lines up with the closing brace:


With the reasoning that by the Principle of Symmetry, your mind will see the open and closing braces and more quickly be able to perceive the code block naturally.

  • After taking a few minutes to apply our code format with them, they were quickly able to see the bug that they had missed before. This is not because your code format helped them see the bug. It's because the task of reformatting code forced them to look carefully at code that they were just skimming over before.
    – Brandin
    Commented Feb 14, 2015 at 22:39

No matter what language or tool you use, come up with something. Configure your IDE and check in the configuration file.

When anyone checks out the project, they will use the same formatting styles. It does not matter what the style is, only that it is consistent. I have my own preferences with regards to spaces v. tabs, and which line the curly braces go on. But more than my own preferences, I just care that a given source code file agrees with itself. It makes it so much more readable than it being a mishmash resulting from a format war.


The worst thing I've encountered so far is using no coding standards. And you are prohibited to make some code block more readable because it breaks diff tools... Because we are using patches to apply changes (change/bug fix request -> fix/change -> patch -> patch applied by "trusted" person -> commit) you can get pretty funny looking source code (from readability point of view). At least we do not have anyone using two letter variables (-.

[rant] The funniest thing is that everyone agrees that we need to change this. There were even a couple of reformat attempts (automated on commit), but because a single tiny itsy bitsy formatting option is missing - the all thing just got through out. Sight... [/rant]


Guidelines help improve quality of code:

  • from the writer point of view: many rules aim at reducing the introduction of bugs. For instance, a rule stating that if() or for(;;) constructs must be followed by a block and not a single instruction, makes intention of initial coder explicit and helps next coders maintain this.

  • from the reader point of view: code that follows agreed guidelines is reviewed more efficiently than code with various styles. The reviewer knows better with less effort where to look for possible bugs.


There is no universal standard for what a team should or shouldn't do. Some teams need to follow strict guidelines, some don't.

The point is, you should work together as a team and decide what is best for your team. Code should be easy to read, because it is read orders of magnitudes more times than it is written. If your team needs guidance to create readable code, stick to a coding standard. If you don't, don't.

All that being said, I think most teams would benefit from agreeing on a standard way to name variables, functions and classes, position braces, and so on. If the team can't agree on something as simple as that, how can they expect to come together and make the really important decisions? Plus, your team won't be made up of the same people forever -- people leave, new people are hired. The easier it is for new people to grok the codebase, the quicker they can contribute to the team without lowering the quality of the code.

Not the answer you're looking for? Browse other questions tagged or ask your own question.