It's been twenty years now since Brian Kernighan and I launched our writing careers with a little book called The Elements of Programming Style (McGraw Hill, 1974 and 1978.) As far as I know, we were the first people to use the words "programming" and "style" in the same breath. In any event, programming style has since been considered a legitimate topic of discussion in polite circles.People still disagree, however, on how seriously to take the whole business of programming style. Some of us are fanatical on the topic. We feel that a rigid style eases the interchange of code maintenance among programmers, and dramatically improves the usefulness of tools such as grep. Others see style guides as attempts by a Prussian management to stifle innovation, or as Procrustean efforts to give intrinsically dissimilar programs a misleading similarity. The truth, as always, lies somewhere in between.
People disagree even more violently on just what style to adopt. I note, with some amusement, that several of the macro names used in this article are ones I pioneered in the earliest days of C. The amusement stems from the fact that I now disagree with their use, and with many of the other rules spelled out here. Tastes vary, and they change.
That did not, however, stop me from accepting this article for publication. I believe it is more important to have a uniform set of style rules than one that is compelling, or even widely admired. I believe even more in having tools for enforcing style rules and in looking for lapses that might indeed represent coding bugs. This article illustrates both of those principles well. Even if you too disagree with some (or many) of the style rules presented here, please don't dismiss the underlying message lightly.
P.J. Plauger