Re: Bad coding standards

[David Emery <emery@mitre.org>]

For a while, I collected coding standards as a hobby.  I've
seen some dumb ideas, but here's my nomination for worst idea:

   package Long_Descriptive_Name is
      
      package LDN renames Long_Descriptive_Name
      
      type T is ...

   end Long_Descriptive_Name;

   with Long_Descriptive_Name;
   package A_Client_Package is
      package LDN renames Long_Descriptive_Name;
   
      procedure Proc (Param : LDN.T)...
   
   end A_Client_Package;

In this style, the existence and use of the rename was not
an option, but was mandatory.  Furthermore, there were no
rules for how a rename would be formed.  In some cases, the
abbreviation related to some previous name for the package.
I once sent out a "test" with 10 abbreviations for common
packages, asking how many people recognized the renames.  The
best score was 8 out of 10, and the average was about 5.

In my example, things don't look so bad.  But when you're
buried in the middle of the code, and you see things like

      Obj : Abbr.Object;

      ABC.Munge (XYZ.Func (Obj), QRS.Enum, ADX.Scalar);

you rapidly lose the redability of Ada, as you have to go find
the damn renames clause to remember what ABC and QRS were.

As one of the first "maintenance" programmers (I rewrote one
unit twice, the first for time and the second for space...), I
found this to be incredibly hard to read.  My first action was
to replace the abreviations with the long names, so I could
figure out what was actually going on.  And after I left, they
paid someone to go through my code, replacing my Nice_Long_Name
qualified expressions with their standard NLN renames.  Ugh!

         dave