I still find coding standards to be a very good idea.

I fully second Ignatius.

In particular, I appreciate your comments about the PEAR standards. I have been adopting them for my own use and at work, and I find that by following a standard — any standard — I improve my own efficiency. Since PEAR is a published standard, it only makes sense to use that instead of haphazardly developing my own.

I have to disagree with two of your comments. The exceptions you have to the PEAR standards were:

1. aligning equal signs should be discouraged
2. The braces policy for functions should match that of control structures
3. embedding inheritance heirarchy into the class name is bad

I agree with point 2 completely; it irks me that the standards define the same situation differently based on context. Either put all open curly braces on their own line, or don’t. (I use VIM, and the former is actually more efficient in that editor when bouncing through it.)

However, I disagree with your other points, precisely for reasons you outlined yourself.

In point 1, I find that aligning equal signs provides a more efficient way of scanning through code — it’s easier to determine what variables are getting set to what values because I don’t have to determine where the equal sign is — all equal signs are in the same place. In addition, when editing, it becomes trivial to select a block including the variable names and equal signs in order to transform that block (for instance, to create an array of values instead of many variable assignations). (Those familiar with VIM and its visual blocks will know what I’m speaking about.)

In point 3, again, I find that naming classes as PEAR suggests is efficient — I can tell from the class name where in the directory hierarchy to find the class’ file. It also makes it easy to build __autoload() functions that utilize the classname to find the file containing the class — change underscores to directory separators, and you’re done.

As this post testifies — there can be many reasons to adopt one standard over another, and debate will continue after the standard is set. However, the real debate is more a matter of determining what standard you will use than debating all the points about them. I would certainly favor changing how opening curly braces are done in PEAR — but unless the PEAR standards change, I’ll do as they outline so that I’m following a known standard — which will make my coding style predictable to other programmers — and hopefully help them be more efficient when modifying my code.

- aligning equal signs should be discouraged.
- The braces policy for functions should match that of control structures
- embedding inheritance heirarchy into the class name is bad

Quite honestly, those differences would not even matter in the one area where coding standards really matter — development teams. I don’t know many teams whose productivity was effected by aligned equal sign confusion.

You and Paul both have an impact on the PHP community. I wish you would spend your time presenting and debating the best ways to implement data abstraction, or front/page controllers, or templating, or MVC, or authentication/access control, or etc. rather than this stuff.

Not to feed the flame which I’m trying to extinguish (i.e., style wars) … but who says that, for example, “saving keystrokes” is a useful criterion? If that were the case, all variables should be named with the absolute fewest characters. This is getting into the area of “philosphical difference” — one can choose the means by which to judge the style (fewer characters, greater descriptive verbosity, whatever) and pronounce that Style A is “better” than Style B … but that’s only according to the criteria you set up. Nobody agrees on an “objective” standard which stands somehow “outside” personal preference, simply because style is itself personal preference. In the broad outlines we can agree on goals (readability, consistency, maintainability) but those are equally good for each defined style, provided you are familiar with the style.

My point, and I think we agree (as you note above) that it’s better to pick a defined style and adhere to it than to nurse your own style. This is not becaase one style is objectively “better” than another (because that’s a matter of preference), but because the social effects of having common styles is more effective in distributing workload.

Hope that clarifies what I meant by “objective” … maybe that’s not the right word for my meaning. Thanks.