Coding styles are THE religious debate of the Engineering industry. Everyone has an opinion, but no one has an iron clad argument as to why their ideas are better than someone else’s.

It doesn’t matter what language you write your in or what company your work for or even what project you contribute too, the topic of coding styles will sooner or later raise its head. The debate can range from the banal, like which line the curly brace goes on, to the overly subjective, like how to name variables.

In the end most of the decision points are pretty subjective and it is somewhat irrelevant what you choose, as long as everyone agrees and you are consistent. But don’t be mistaken, a consistent coding style is an important consideration on any project, from the solo developer to the multi-national team.

Quality At All Levels
The quality of a piece of software starts with the source code itself. It is simply not logical to expect that a software product will consistently and reliably meet the expectations of its users over any length of time when the very bones of the software are of low quality. A consistent style applied and adhered to across a project brings an inherent level of quality (and craftsmanship) to the source code and that quality naturally flows on to the end product.

The Big Yellow Bus Factor
A common syndrome in software development companies is the Hero Developer. The Hero Developer is the one who takes on the rogue projects, knows “the core” better than anyone else and basically works out in front of the rest of the team. Often the code produced by Hero Developers is idiosyncratic, cryptic and about as readable as a doctor’s prescription. And this all creates a barrier to other developers learning those parts of the system. Unfortunately when the Hero Developer is out getting lunch one day and gets hit by a bus crossing the street, the team is suddenly in big trouble.

Most Are Not An Island
Any project bigger than a bread basket will inevitably involve more than one team. Sometimes the teams are from the same organization and other times the teams might be from multiple organizations (an internal team plus an outsourced offshore team for example). Either way, it is complicated enough having multiple people crawling over the same code base during a project, let alone having multiple teams that might be geographically and temporally isolated from each other. A consistent code style is going to lower the collaboration barriers between these teams.

Outsource On Autopilot
One of the big problems when outsourcing a large development project, particularly when the project will be maintained by an internal team after go live, is making sure the code that is delivered is usable and maintainable. One tactic to help with this problem (although not a complete solution) is to provide the outsourced team with a document outlining your internal team’s coding standards so that they can adhere to them as well. Thus, when you get the code back, you will have some chance of comprehending what has been written. Even if you do not intend to maintain the code base yourself initially, relationships can change or breakdown and if you are confident you can take over the code base, you will not be forced into renewing a contract that you don’t really want to.

A word of advice on this front – make sure you provide your coding style guidelines to the outsourced company during the contract negotiations, not later when the coding begins. I have personally been witness to a meeting where an outsource company argued that adhering to coding standards would slow them down and hence the costs would have to go up. Nothing makes me want to scream more than hearing people argue that delivering quality code takes longer than delivering (presumably) a spaghetti tangle of code. The project would not have taken longer to deliver, but the outsourced company had an easy argument to make since the standards weren’t discussed during contract negotiation. Unfortunately at the time I didn’t work in an organization with a strong commitment to quality at all levels, so the outsourced company was allowed to continue on their cowboy coding ways.

Craig’s Rule: The quickest path to delivering a software project that is actually usable by its intended audience is always, always, always the path that includes the highest quality.

The New Kid On The Block
The learning curve for a new team member can be incredibly long and steep. Being able to read and comprehend the code base is a very large portion of that hill that needs to be climbed. Consistency across the code base will obviously increase the speed at which this happens.

The 80/20 Rule
If you believe the old adage that 80% of the life of code is in the maintenance phase, then writing code that is easily maintainable is obviously a worthy goal of any project. When adding new features, fixing or code, developers often find they are playing with areas of the code they have never seen before (because the original developers have rolled off the project) or it just may be that they haven’t seen that code in a long time. So the human readability and ease of comprehension of the code is paramount to decreasing the effort expended during the maintenance phase.

Avoid Merging Hell
This last reason is not as obvious to most developers, but is well known to any seasoned developer or any folks. Almost all source code management (SCM) tools support the concept of branching code bases. Branching a code base allows parallel development efforts, without those efforts interfering with each other. The classic use case for branching is fixing bugs in an already released version of the code while also working on features for a new release. Branching is useful and necessary, but when it comes time to merge those branches back together again, you can quickly find yourself in a nightmarish scenario. Many times you will find conflicting changes in the branches and the person doing the merge has to tease out which change to keep, which to blow away, or maybe merge the changes together.

This problem can be horribly exacerbated by stylistic changes being made to files. SCM tools usually cannot tell the difference between a meaningful syntactic change and a cosmetic style change and it is left to the person doing the merge to figure out which changes are important and need to be merged. There is nothing more frustrating than having an SCM tool report 200 changes in a single file and after spending 2 hours reviewing the changes, you realize that the developer just hit the reformat button in their IDE and that process moved every curly brace onto another line. Having a consistent coding style can eliminate this problem and so the person doing the merge can be confident that any change reported by the SCM tool is actually a change they need to be concerned about and make sure it gets merged.

A consistent coding style that is adhered to and even enforced deliberately offers many upsides – not the least of which is stopping all those water cooler debates about where the curly braces go (btw, the correct answer is on the same line as the start of the code block, not the next line!).