Why Coding Standards Matter

David Mytton writes about coding standards on Sitepoint.

A coding standards document tells developers how they must write their code. Instead of each developer coding in their own preferred style, they will write all code to the standards outlined in the document. This makes sure that a large project is coded in a consistent style — parts are not written differently by different programmers. Not only does this solution make the code easier to understand, it also ensures that any developer who looks at the code will know what to expect throughout the entire application.

I completely agree.

When you start sharing code, or start reading code shared by others, you begin to realize that not everybody writes their code they way you do. You see that other, ugly coding style, and think “everybody needs to write in the same style so that things are easier for me to understand.”

Thus, it is natural that everybody wants their own habits turned into the standard, so they don’t have to change their habits. They’re used to reading code a certain way (their own way) and get irritated when they see code in a different format. The thing about defining a coding style standard is that there is no objective means by which to judge one style as “better” or “more-right” than another. Sure, we can talk about “readability” and “consistency” but what is readable is different for each coder (depending on what they’re used to) and consistency follows automatically because, well, why would you use another style?

Other than in the most broad outlines, defining a coding standard is an exercise in arbitrariness. Who says that a 75 character line is better than 72, or 80? Who says putting braces in one place is better than putting them elsewhere? And who are they to say; by what standard do they judge?

The point of a coding style standard is not to say one style is objectively better than another in the sense of the specific details (75 character and one-true-brace convention, for example). Instead, the point is to set up known expectations on how code is going to look.

For example, look any PHP project written by more than one person. If you examine Script A and see one coding style, then examine Script B and see another, the effect is very jarring; they don’t look like they belong to the same project. Similarly, when Developer Joe (who uses one coding style) attempts to patch or add to a separate project from Developer Bill (who uses another coding style) the mix-and-match result in the same project (or even the same file!) is doubly jarring.

As PHP developers, we need to define and adhere to a coding style not because one is better than another but because we need a standard by which to collaborate. In that sense, coding style is very important; not for itself, but for the social effects generated by adherence to defined standards.

It is for this reason that I abandoned “my” coding style to adopt the PEAR coding standard. Sometimes you need to give up a small thing to gain a greater thing; by giving up my coding style, I had to change my habits; but now, anybody familiar with the PEAR standard can read my code and add to it in a recognizable way.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

21 thoughts on “Why Coding Standards Matter

  1. I think I would fall into Harry’s group of it not being at the top of my list. However I think standard interfaces would help the PHP community a lot. I care less about capitalization or where the braces are, and more about consistent naming of core functions common across many libraries/classes. That incosistency has always been a weakness of PHP.

  2. Hi, Harry; hi, Chris,

    I agree that something like coding style is boring, as well as being an invitation to flamewar between “fanboys” of differing styles (as well as opening up a forum for “style Nazis” who have nothing better to do than point out where you used tabs instead of spaces ;-).

    I wouldn’t call it the top of my list, either, as far as style by itself is concerned. However, I would say that defining and then adhering to a coding style standard is one of the little things — even a foundational premise — that makes it easier and more enjoyable to collaborate on a project, especially when the coders themselves have only the Internet to communicate with (i.e., no face-to-face social environment to work in).

  3. […] Tendo dito isso, um entrevistado resumiu o que parecia ser um sentimento comum desta forma: “A maioria das pessoas provavelmente vai concordar que é sobre um acordo em um padrão, e em seguida, ser coerente com ele”. Eu acho que é frequentemente o caso com os padrões. […]

Leave a Reply

Your email address will not be published. Required fields are marked *