Bad coding standards

["Marc A. Criley" <mcquad@earthlink.net>]

(was Re: constant string array)


Ken Garlington wrote:

> I say, why stop at one set? I think a nice rule would be to encode tests in
> double parentheses, similar to label constructs, i.e.
> 
> if ((a * b + c)) then
>   ...
> end if;
> 
> so that, if you're doing structural test coverage analysis, you can find the
> essential elements easily. Wouldn't that just be a lovely standard?

I tried really, really hard to not start talking about bad coding
standards I've encountered, but I just can't stop myself!  :-)

Here's my top 3, in no particular order, thankfully each of which
occurred on a _different_ program:

- The first letter of each source line was to be capitalized, and _all_
  other words, reserved and user-defined, were to be lower-case.  One
  exception was permitted--for the "end xxx" construct, where "xxx" was
  "if" or "case" or the unit name, etc., "end" was also to be
lower-case.

  (The rationale for this practice was that it would "make the text more
  readable", since it conformed to the capitalization practice of
English
  language sentences.  I went round and round with the author for years
  on this one; he finally retired and I rewrote the standard.)

- No subtypes.  If there is a situation where a new type that is related
  to an existing type would be useful, _derive_ the new type and use
  explicit conversion when values of types in the derivation tree have
  to interact, do not use subtypes.

  (This, I believe, was a result of some rabid "type zealotry" that
  felt that subtypes allowed sloppiness and a way of working around
  strong typing.  Fortunately this program was being relocated and had
  lost most of its developers when I joined up, so we were able to
  ignore this standard until I had a chance to rewrite it.)

- No child packages.  No "aliased" objects.  Basically, no Ada 95
  language features, except for the new packages like the Strings
  and Interfaces ones.

  (This standard actually was more verbal than documented, and was
  caused by the project being ported to Ada 95--and a new compiler.
  The personnel had had no exposure to Ada 95, so it was simply
  decided to forbid the use of the new features.  I was able to bring
  in a lot of experience with the features, and so with some guidance
  the developers were permitted to start exercising Ada 95's
  capabilities.)

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com