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.
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:
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.
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.
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.
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.
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:
if(true)
{
}
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.
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.
