Coding standards and coding style, is it that much important?

Question

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.

Answer 1

http://www.codehustle.com/2011/06/c-coding-conventions-and-standards.html

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.

Answer 2

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).

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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!

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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? ;-)