Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

There are a lot of ways of typing code, but I can't understand what is the good reason to adopt a certain standard or style if it does not change the way the code can be read and understood.

Everyone can type code the way (s)he thinks it's better, but is there a really good reason to force all programmers for a certain style ?

Does it really make a difference in the end ? Is it for pleasing the managing folks, or the control freaks ?

Apart from this post about those very stupid coding standard, are there companies who encourage employees to choose what works for them ?

EDIT: Wow thanks for the answers, the thing that made me post this is the BSD vs K&R brace style: this is a big issue, and this really made me rant.

share|improve this question

closed as primarily opinion-based by MichaelT, Thomas Owens Jul 23 '14 at 17:14

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

"if it does not change the way the code can be read and understood" - Ah, but what if it does? –  nbt Jun 15 '11 at 14:37
They are important. But if they are more than one page and not negotiable, I would rather not having them. –  Codism Jun 15 '11 at 17:43

16 Answers 16

up vote 25 down vote accepted


The above is a link to a blog post that I wrote the other day about coding conventions. The main thing about coding conventions is that it provides consistency. Consistency is important in a team environment for a number of reasons. For one thing, if someone else is reading your code and you use different naming conventions, styles and different tabulation than the user expects, he will have to waste a little bit more of their brain's CPU cycles parsing the code rather than focusing on the content. Further, employing consistent conventions is beneficial to you because it fosters best practices and keeps your API consistent.

As an example, think about how much easier your code would be to read if all of your class names, function names, public properties, etc. used PascalCasing, while your local variables used camelCasing. You can immediately identify the scope of a variable simply by how it is typed rather than having to search for its definition.

Anyway, coding conventions keep your code clean, consistent, and easy to read. This is good for maintainability and helps reduce errors.

share|improve this answer
@John: Thanks for trying to answer the question, can you please place some addition text into your answer regarding what the link contains? This is in the advent that this site goes down or link structure changes and we can preserve the content of that link here for future purposes. Thanks and welcome to programmers.SE! –  Chris Jun 15 '11 at 14:40

Imagine that one day they have canceled all of the traffic and airway rules and policies. Now everyone can drive and fly wherever, whenever and however one wishes.

At first glance it seems like an awesome idea, no more stupid rules to hold you back and interfere with your timetable.

But then you notice that you can't quite get far. As everyone did like they wanted the roads turned into an anthill and the airspace started to look like the Brownian movement. Any attempt to get through would at best not succeed and at worst get you hurt. Any roundabout way you would try would already been blocked by the other traffic participants who tried to get around the same way.

Software development is not different. It's easy to start ad hoc and do it as you please. It is relaxed and fun in the beginning but it turns into a mess quite soon and then becomes a very evil and perverted kind of torture only programmers can appreciate.

The rules and guidelines keep the order from falling into an abyss of chaos.

share|improve this answer
Bad analogy. Better, you should consider that "style" and "standards" are more like CSS of a web site, rather than life-and-death matters of air traffic control. –  S.Lott Jun 15 '11 at 15:12
poor analogy. Coding standards are more like being allowed to choose the kind of car you want to drive. A country with standards you describe would be Iran, where every car is a beige Paykan. You're describing standards of protocols where you need a common specification, but coding standards need to be more flexible - in this analogy, being able to drive a yellow Beetle or a red Ferrari with an automatic or manual transmission .. as long as they both have legal lights and tyres and you drive them on the correct side of the road. –  gbjbaanb Jun 15 '11 at 15:45
@Peter Rowell: It's called a meta analogy - an analogy about analogies. –  user8685 Jun 15 '11 at 18:24
And I can honestly say I never meta analogy I didn't like. <rimshot> Thank you, thank you, I'll be here all this week. –  Peter Rowell Jun 15 '11 at 18:39

Code is often written once and read many times. This is the reason for all coding conventions. Yes, any one can write the code they way they think and in the style that makes sense to them. The problem comes up when someone else has to read the code and has no idea what is going on. Having a code base that looks different depending on what section of code you are in can be confusing when someone has to come in and fix a bug. Having a set style and convention of how to write code for each project makes it easier for other people on the team to help improve a section they did not write. This is especially true with the fact that the person who wrote the code might not be with the company anymore.

share|improve this answer
It also reduces noise in commits: if one person like One True Brace Style and another person hates it, without a style guide the commits end up with edit wars over things like where your {}s go. –  Frank Shearar Jun 15 '11 at 15:49

Consistency & Collective ownership should justify alone that you follow the industry (or team) standards in order to produce value.

If you want your own style, create a company or work on your own projects at home.

share|improve this answer

The first rule in Sutter and Alexandrescu's C++ Coding Standards is, "Don't sweat the small stuff."

I remember a meeting created by a past manager to decide where to put the '{' character. It turned into a 2 hour argument. People on one team wanted it one way, people on another team wanted it another way.

I've seen superfluously large documents that describe nothing BUT where to put '{' characters and other trivial nonsense.

It's a completely useless waste of time. Coding standards should be about important things like, "Have a unit test for every object," or, "Never expose a raw pointer through a public interface, always use a smart pointer alternative." The above mentioned book is in fact a very good one although even they can't help step into suggesting standards for variable names that seem to me pointless. Where they stick to technical issues though they are hard to argue with.

share|improve this answer

Being slightly OCD I am very passionate about codding styles being the same for a given project even to the point of installing StyleCop and making it break the build if something doesn't conform, but that is just me.

Take this excerpt from "The Art of Agile Development" by James Shore & Shane Warden on Coding Standards. They start of with a one liner:

"We embrace a joint aesthetic"

And go onto say:

Individual style is great when you're working alone. In team software development, however, the goal is to create a collective work that is greater than any individual could create on his own. Arguing about whose style is best gets in the way: it's easier to work together in a single style.

However, they go on to say, and this is the important bit:

A consistent formatting standard is good. If you can agree on one, do! However, when you're putting together your coding standard, don't fall into the trap of arguing about formatting. There are more important issues.

Essentially what they go onto say is come up with the minimum set of standards that you all agree on within the Team. One you have a standard in place you will have something you can continually improve on without putting anyone's nose out of joint.

share|improve this answer

It only matters if there's more than one person that will be working on a given project. As a manager, if you anticipate that the current developer will eventually move on or be replaced by another (which is an almost certainty), then it's in your best interest to have a consistent code style and certain architectural conventions in that project.

Say you've got DeveloperA and DeveloperB working on different projects ... if DeveloperA is sick for a whole week and you need DeveloperB to work on a bug fix for his project, he will get up to speed a lot quicker if there are similarities in project organization, branching strategy, and architecture.

To flip the perspective, as a developer, it is in your best interest that your buddy in the next cube is writing code that "looks" similar to yours. The reason here is the same as above ... if you are DeveloperB, you don't want to have to figure out the little quirks in his code style if you ever have to delve into his codebase.

How many people have worked on projects where you can tell who wrote a piece of code just by looking at it? ;-)

share|improve this answer
But maintaining consistency even in absence of a written/established standard in your code as a sole developer is still important. You may be the only one writing code right now, but you may not forever be the only one writing and reading the code. –  Michael Jun 15 '11 at 15:35

Some people do use coding standards as a crutch to get around bad code. I have seen people act as if the only keys on the keyboard where control, v and c but claim that their stuff is ok because it follows all the standards.

They are like a dress codes. It can't fix inept personnel but it can at least provide the appearance of constancy and people absolutely adore consistency.

Also like a dress code there is some actual value in the seemingly arbitrary rules. Following a strict dress code means the individual doesn't have to think about certain details thus freeing them up to think about their real job. It also lowers conflict because people can't argue about what fashion is better due to the fact there is only ONE fashion.

There are some big problems with all arbitrary rules. One is that when something changes or something new is encountered that the rules don't cover all hell can break loose. Another HUGE problem are that many developers tend to be a tad pedantic/Obsessive-Compulsive. Dealing with those people can just drive me crazy when the error is something absolutely silly.

So really, like all things, it comes down to the people you work with. If they are professional, reasonable individuals that understand that code, like life, is a compromise then the standards are wonderful things that helps everybody. But if you work with losers that only care about what makes them happy then the standards will be a weapon that they use to slowly kill your soul.

share|improve this answer

A simple practical example not needing too much elaboration:

Programmer Bob prefers to use 4 spaces for code indentation.

Bob's colleague, Programmer Alice prefers to use literal tab characters.

Bob and Alice collaborate on the same Python code file, each using their preferred indentation methods. Now when the code is run, it completely breaks because whitespace is significant in Python. A previously agreed-upon coding standard would have prevented this.

share|improve this answer

I agree that some form of standards are good, btu I really disagree when I see some of the trivialities that usually end up in most standards.

Generally, coders will work to an established style anyway - they will try to make their code look like the code that's already there, so writing down a heap of 'you will do x' rules is just annoying and pointless. If anyone doesn't come up with code that follows the team's implicit guidelines, then you can be certain that person is not a fully-signed-up team player and you can have words with them.

The standards that I do think are important are to do with structure and organisation of code - not to say how many lines of whitespace need to be between each method, but how it'll be laid out in your SCM; what kindof folder structure to aim for; where to put the binaries and the release notes.

If you've ever seen several open source projects, even those that have their own standards, you'll be able to view all their different code and understand it. How many OSS projects have a dependant project that follows a different coding style? how many coders worth their salt can read both code styles and understand the codee, even though they don't use the same standard!?

I find it sometimes takes a lot more effort to find out where the binaries get built or how to find the readme that tells you how to set up the dependancies. So at my place, we focus much more on standardising these things so anyone can grab a project and will immediately know where to find a readme that will tell you what kind of project it is they're looking at or where to find the binary to install. It also has the benefit of forming some partof the documentation and geting rid of the 'grammar nazis' that love those officious old coding standards!

share|improve this answer

Coding standards are one element of software quality assurance. Use of them depends on the software QA level applied to your software. We assign a quality grade to all applications. In general, the grades are:

  • Level 1. Life critical.
  • Level 2. Safety critical.
  • Level 3. Business critical.
  • Level 4. Not critical.

In general, coding standards are not required for level 4 applications. They are strongly recommended for level 3 applications, and are mandatory for level 1 and 2 applications.

Most languages seem to have generally recognized good coding practices. They make a good fallback if a manditory coding standard is not used.

share|improve this answer

It is probably one of the aspects that for entry-level programmers, is incomprehensible. When I got my first job, everyone was talking about coding style and coding conventions but I never really gave any attention to it. Up to that point, my only experience was coming from university projects, where I was either the single programmer, or if it was many of us, we wouldn't really pay attention to the code quality. I had no experience over huge code bases handled by tens of developers simultaneously. When I had to dig into other colleagues' code and understand it, I realized the importance of a unique coding style for the whole project. I could move back and forth from one module to another, without needing the time to warm-up and get used to the developer's style. Getting used to the conventions and eventually using them, is a huge time-saver in the longterm, and saves incredible amounts of frustration.

Coding conventions increase the signal to noise ratio of a software project. They increase the accessibility of another individual's code, and create a common work ground for all.

I would say that, If the programming language is the communication means, the coding conventions are the dialect.

share|improve this answer

It is important for future maintenance. In our company the team that writes the original code will often hand it over to a different team for maintenance. Typically this maintenance team speaks English as a second language. So by having code and architecture standards it is easier for them to ramp up on a new system.

share|improve this answer

I think that naming standards are very important so you don't have to guess if the method is doSomething or do_something, or DoSomething or do_Something, etc...

Formatting standards are good however I feel they are not as important. The rule of thumb I try to use for formatting is to keep the file consistent (even though I break this quite often our of habit of formatting my code the way I naturally do).

share|improve this answer

As long as coding guidelines are what they should be - just guidelines, they serve as an important input for code review. However, code review has become more subjective these days in that it has become "how people code in this company/project". I personally believe most of the guidelines that come with the language itself would be sufficient. For example, Microsoft provides almost all of these standards on MSDN. This should be sufficient unless one codes for a moon probe.

In a nutshell, a coding guideline document should ideally have a set of links to the language provider's website.

Unfortunately a lot of code guidelines these days try to put author's preferences into the heads of the developer, which is the last thing anyone would want in a creative business like software development.

share|improve this answer

It's ironic, in my mind, that there's a certain sort of puritanical developer who will:

  • Drone on and on about separating content (HTML) from presentation (CSS), but then
  • Expect his colleagues to simultaneously program and format code to his liking

Isn't the same basic issue in play for both items? If we're supposed to be able to focus on content and abstract away presentation, why is it that programmers themselves don't enjoy the benefits of this strategy?

(I guess what I'm saying is that style doesn't matter. Standards are another matter, although we may disagree on what the standard should be, and sometimes there's room for the standard to remain silent on a topic.)

share|improve this answer

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