You are reading, a personal blog about software development.

The conventions we follow

I don't think programmers are considered to be an especially emotional bunch. But one thing that we can certainly be emotional about is the formatting and layout of code. My eyes bleed when I see an opening bracket on the same line as a function. My knees hurt when people don't leave exactly one blank line between two functions. But here's the thing - unless I am coding on my pet project at home, my personal preferences doesn't really matter. And as a member of a team, your personal preferences shouldn't matter to you either.

It's easy to confuse a coding style with a coding standard as these words are not used consistently. I consider a coding standard to include both a coding style and additional rules that go beyond merely formatting. For example, a rule like "functions returning success or failure shall use an integer as return type" does not belong in a coding style. Within the context of this post a coding style refers simply to a document describing how code should be formatted. The rules set out in a coding style typically cover topics like:

A coding style is written for a specific programming language and can be seen as "the conventions we follow". If you are lucky you were at the company at the time things were being agreed upon, but reality is that coding styles often see many developers come and go through their lifetime. In my eyes there are three major advantages to using a coding style:

Make code easier to maintain

Software implemented by one programmer today may need to be maintained by another programmer tomorrow. When coding style is consistent across the code base the other programmer is able to quickly glance at new code and infer meaning to it based on the conventions used. If your coding style specifies that only constants shall be written in all caps, then you can infer that a variable is constant when you come across an all caps name. Similarly, if your coding style specifies how package imports shall be ordered, then you immediately know where to look for one. This makes the code easier to maintain.

Support collective ownership

Collective ownership means that all programmers are responsible for all the code. Collective ownership is a good thing because it increases the bus factor, i.e. the number of programmers that can get hit by a bus before the project suffers terminal illness. Sticking to a common coding style throughout the code base makes the code comfortable for all developers to work with.

On the contrary, programmers using their own personal coding style in a large code base, may end up starting a battle for territory, not unlike our friends from the animal kingdom:

Scent marking (also known as spraying or territorial marking) is behavior used by animals to identify their territory. Most commonly, this is accomplished by depositing strong-smelling substances, sometimes by urinating on prominent objects within the territory. Wikipedia.

Personal coding styles are like dog urin and big fat fingerprints. They leave marks in the code and create barriers between programmers.

Settle those lengthy discussions

Every programmer has strong feelings about coding style. These feelings are rooted in vanity and a discussion with a college regarding whether to use white space around keywords is likely to get heated. But guess what - it really doesn't matter. You will gain the advantages of easier maintainability and collective ownership regardless of how you use white space around keywords, as long as you all do the same thing. In these situations, just follow the coding style blindly.

You don't have to like it. If you are not satisfied with a certain rule, just direct your anger towards the coding style like the Christians direct their anger towards God. And then get on with some real work. This is much more constructive than engaging in lengthy discussions about things that does not matter.

Just having a coding style will not benefit you unless, of course, it is actually followed. To some extend you don't need to enforce it manually. Many code editors, for example Eclipse, can be configured to enforce coding style. Even if your editor does not support this, there are tools that automatically applies a coding style to a file. In my team we use indent and uncrustify. I have also heard good things about ReSharper. Rules that cannot be enforced automatically, e.g. naming conventions, can be enforced through the code review process you are probably already using.