Re: Bad coding standards

[Marin David Condic <mcondic.nospam@acm.org>]

Ken Garlington wrote:

> We have never had a CMM audit firm do an audit against our coding standards,
> AFAIK, and I can't think of a KPA that would require that kind of detail.
> You may want to consider another audit firm. If you have a customer that
> requires it, that's a different matter -- although, if it's the U.S.
> Government, and it's a new project, you might want to remind them of their
> stated policy related to acquisition reform...
>

Well, it obviously depends on your organization and what is required internally
and externally. I've just personally encountered (internal) auditors who have
dinged us on even fairly lax style requirements. Somebody put in the guide that
"A module shall not exceed 200 lines of code without an explanation in the
banner..." (Good rule or not - it was in the coding standards.) So the auditor
found one module (out of hundreds!) over the limit (barely) without a sufficient
explanation and there was a significant unpleasantness over it for several days.
The point being that the minute you write down a rule, someone sees it as their
job to enforce the rule. Hence, the more detailed and exacting the rules are,
the more misery you are asking for later. That's why I'd prefer a coding
standard that is relatively short and doesn't demand too many precise details.

There are people in the world who are "Control Freaks" or who demand that "The
Law Is The Law!" and you often have to be careful about how they are going to
look at what you write down. Style *should* be something that is consistent and
details help, but you also want a lot of leeway to wiggle if there are reasons
to do so. IMHO, a reliable and properly functioning piece of software that is
delivered on time is more important than a really pretty piece of software that
doesn't work right and/or is late. Strict adherence to style does not
necessarily move the mission forward.

>
> : That is why I would opt for a simpler style guide that is easier to live
> up to
> : and maybe use something more complex as just a "recommended reading" and
> : "suggested practices" for developers.
>
> Personally, I think that perverts the idea of the word "guide," but I
> understand what you're saying.
>

Well, I guess it depends on the "authority" given to the style guide. If all you
do is have it there as the stated style within the team and the team inspects
code against it in a review and only looks for gross violations, then fine. If
its something that is given more weight by, say, your Software Quality Assurance
organization, it can start inter-organization fights, turf wars, etc. that take
time to resolve. That's where I'd prefer a shorter and less precise style guide.

MDC
--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================