I agree with the main thrust, that coding standards can help to make code readable, might help to highlight dubious or buggy code, and should be (machine) enforceable...
...but at the same time, I do not agree that rules can be neatly divided into "fact" and "opinion."
In fact, I would go so far as to say the reason we have so many conflicting standards is precisely because we cannot agree on what is fact and what is opinion. And that's OK.
That document started as a simple set of do's and don'ts. It was, as the OP might have put it, "full of author's own opinions and personal coding style." But it was also the agreed-upon style for the project ("Pink") and had utility.
Another classic example is Hungarian Notation. I suspect you would find a number of people passionately supporting and others vehemently denying its usefulness.
For this reason, maybe calling them "coding styles" may be nearer the truth.
It's about being able to maintain the software for next 3 years. Sure people have opinions but sometimes it's better to agree to disagree and have the discipline
Hmmm, I wasn't saying one shouldn't use coding style guides. Quite the reverse. My point is that it is not whether any particular guideline is "factual" or "opinion," but whether one can get teammates to abide by them.
...but at the same time, I do not agree that rules can be neatly divided into "fact" and "opinion."
In fact, I would go so far as to say the reason we have so many conflicting standards is precisely because we cannot agree on what is fact and what is opinion. And that's OK.
As a case study, I give you "Miss Manners' Guide to C++", which eventually was published as "Taligent's Guide to Designing Programs: Well-Mannered Object-Oriented Design in C++" [http://www.amazon.com/Taligents-Guide-Designing-Programs-Obj...]
That document started as a simple set of do's and don'ts. It was, as the OP might have put it, "full of author's own opinions and personal coding style." But it was also the agreed-upon style for the project ("Pink") and had utility.
Another classic example is Hungarian Notation. I suspect you would find a number of people passionately supporting and others vehemently denying its usefulness.
For this reason, maybe calling them "coding styles" may be nearer the truth.