I *do* understand that Your article was written mainly to stir the water and I actually somewhat agree whit what You say, but I could not help noticing the only thing You managed to "prove" is Your bad knowledge of Mathematics.
You cannot discuss about a theorem.
It's either *proven* or it's not a theorem at all.
You could discuss the postulates the theorem descends from.
What You presented are simply opinions.
Please call them so.
This said I can proceed making a fool of myself expressing my personal opinions on a subject that is evidently a huge battlefield for crusadeers :) :)
1) Coding standards should be considered like "good manners" (or etiquette, if you prefer); When You visit someone's (it is immaterial if it's a home or a program) You should learn how to behave and try to stick to the local rules.
2) Most of the coding standards are just plain ridiculous (like having to put comment headers before "local variable declarations" or "type definitions": if you cannot recognize a typedef you should really stop looking at the code NOW), but that doesn't mean that *all* of them are ridicoulus.
3) I personally hate Hungarian Notation and, where necessary (someone else's BIG code), I compile C++ (with all warnings on) even plain old C to get a better type checking.
4) Coding style, in order to be effective, useful and not an unnecesary burden for the programmer, should be adapted to the project (and here we go back at (1)). My rules are relatively simple:
a) use short names for local variables (wherever possible declare local temporaries in the block that uses them). For this variables I use a Fortran-like notation (if the name starts with ijklmn then it's an integer, pqrs are for pointers to char, c is for chars, etc.).
b) if the project is big enough then all the exported variables (avoid them as plague, if you can!) and functions are prefixed with a short (3 char, usually) indicator of the section of the code they belong to (file, module, section or whatever is appropriate to subdivide the code in sensible chunks).
c) make heavy use of the "static" keyword.
d) enforce consistent indentation style by running indent on the code (expecially when I didn't write it) and then carefully ignore complaints because the comments go messed up. (Yes, I know this is rather drastic, but it works wonders in very short time :) :))
e) encorage documenting the interface to sections of code in the header files (included from the users of the code) and documenting in the code itself (.c) the implementation (algorithms, limitations, todo, ...)
As You see all these are really a cross between coding rules and good programming advice.
I'm completely aganist carving in stone the style rules, but, on the other hand, arrive to some common agreement to ease everyone work is, expecially in large projects, a must.
The bottom line is that (IMHO) coding *style* and healthy coding *practices* are difficoult to separate.
If You try to give only syntactic style rules you are likely to end up with bored programmers and little useful outcome.
On the other hand style is an integral part of coding guidelines.