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.