Re: Bad coding standards

[Wes Groleau <wwgrol@ftw.rsc.raytheon.com>]

> 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.

The problem is when allowing "wiggle room" results in
difficult-to-read-and-maintain software because certain
people will not apply common sense--it has to be applied
by force from outside.

Our solution: Move a few of the "guidelines" bullets in AQS 
into "standards" bullets.  Then define "standard" or "shall"
as "non-compliance requires a waiver signed by _____" and
define "guideline" or "should" as "non-compliance requires 
approval from a peer review team."

We also significantly revised AQS.  Some things we didn't
agree with, others we thought unclear, and it was surprising
how many examples were non-compliant.  (Principle of technical
writing--given an unambiguous requirement in prose and a
non-binding example, if they disagree, the example will be followed.)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau