In fact, there's a general problem with all coding guidelines. One person was burned (or believes it's easy to get burned) by a something, so he finds
"Vladimir Prus" <ghost@cs.msu.su> wrote in message news:200407121609.36583.ghost@cs.msu.su... that
something dangerous. Other person was not burned, so he thinks otherwise. And if no real evidence exists, arguments can become too abstract.
How do they say... all generalizations are false? :o) I disagree. There are coding guidelines that are generally accepted within reason and when the forces are properly explained. For example, virtual functions are preferable to switching on type, for objective reasons (modularity, extensibility, flexibility). Now there are cases when that guideline won't apply, so as long as those cases are identified and spelled out, I think that is a fair coding guideline on which most reasonable people would agree.
It would be great to have some site, where folks could list designs or low-level idioms which lead to bugs. That would gather needed evidence. I used to have such list for myself, so, for example, I'll never write
for(size_t i = ..., i >= 0; --i)
any more ;-) Of course, creating such global list is very hard.
In fact, here's a little guideline that everybody would agree with. :o) Andrei