Comment (In support) (Score 1) 430
Most "coding standard bugs" are hidden in a meta-level of reasoning that is harder to find than solving actual crap code.
True Story: Working at a medical equipment manufacturer writing C++. These two atomic rules, placed far away from one aonther in the standard made a mess. See if you can spot the mess.
(A) No member function may be defined within the class definition, and instead must be defined in the translation unit for that class. [e.g. you have to put the member definitions in the
(B) Access to member data may only take place via "getter" and "setter" functions. [as opposed to putting the varialbes in the "public:" part of the class.]
Both harmelss enough by themselves. But I opened a crap-ton of bugs on this issue because the two rules taken together turned simple register load/store operations into unoptimizeable far calls between translation units for each get/set operation. So I put my getters and setters in the class definitions like a sort of sane person (I didn't try to force sanity on them complely and just make some of the trivial values public, as I don't think they could have taken the strain) and, as required by the version control integration with the codeing standards enforcement and bug tracking tools, I filed a request for exception for every single damn such usage and let them choke on their procedure.
But there was a reason that only _my_ code didn't run over its CPU time budget.
A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. -- Emerson.