Since writing On Coding Standards and Code Reviews, several people have asked me:

After all, you pay an opportunity cost in that time and energy spent on these activities might be better spent elsewhere.

I should have thought about this earlier because it would have helped focus our coding standard effort on tangible business benefits.

To remedy that oversight, I list below what I see as sound reasons for having a coding standard and for performing code reviews.

Why Have a Coding Standard?

Successful software tends to live a long time: bugs are fixed; new features are added; new platforms supported; new versions of the language and its libraries released; the software adapted to new markets. That is, successful software development is a long term activity. If you plan to be successful, you should therefore plan for your code base to be maintained by a succession of many different programmers over a period of many years. Not planning for that is planning to fail.

Put another way, it's the difference between Programming "Hey, I got it to work!" and Engineering "What happens when code lives a long time?". A quick one-off hack is fine if the code only needs to run a couple of times ... but not if it becomes a long-lived critical feature.

Programming is easy, Engineering hard. You need to hire programmers with sound technical skills and domain knowledge, enthusiastic, motivated, get things done, keep the code clean, resilient, innovative, team players ... and then motivate them, train them, keep them happy so they don't want to leave, yet have effective handovers when they do ... a hard problem. Yet to be successful that's what you need to do.

This is the primary reason why you want a company coding standard: to make long term code maintenance easier.

Notice that if you choose instead not to mandate a coding standard, you'll likely end up with an informal one anyway, as some strong personality in your organisation fills the vacuum by evangelizing their own set of pet coding rules.

The goals of a good coding standard are:

The above list represents real business benefits which should help you decide what to put in your coding standard and what to leave out. My experience here is that shorter is definitely better. The longer your coding standard document, the less likely that it will be read, understood and followed.

Why Perform Code Reviews?

Of course, code reviews are not free and there is an opportunity cost in that time spent reviewing code means less time spent on other activities.

How Can Coding Standards Improve Development Speed?

Mainly in areas of Cross-cutting concern. For example:

Update: as noted by gwadej below, style guides should be separated from coding standards. Stronger, I feel style guides should be enforced/automated by a tool (e.g. Perl::Tidy), so as to avoid wasting time in unproductive arguments about indentation, brace placement, and so on.


References Added Later

Updated Nov 2018: Added new "How Can Coding Standards Improve Development Speed?" section.