RE: Bad coding standards

["Robert C. Leif, Ph.D." <rleif@rleif.com>]

From: Bob Leif
To: SteveD et al.

A very simple solution to producing and using a name with a reasonable
length  is to do all the renames at the beginning of the Ada source. This
produces a Table of Contents. In fact, if one uses any but the most common
abbreviations for any purpose, the also should be listed together.  One of
the beauties of Ada is the source text can be organized as a readable
technical document.

--*********Table of Contents********
Package Analyze_Type_Declaration renames
  Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
--*********End Table of Contents********
--I presumed Analyze_Type_Declaration was a package

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of DuckE
Sent: Thursday, December 14, 2000 7:19 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Bad coding standards


[snip]
> is not so terrible. Given the choice of the following
> three possibilities in the GNAT compiler context:
>
>    Analyze_Type_Declaration;
>    SC3.Analyze_Type_Declaration;
>    Semantics_For_RM_Ch_3.Analyze_Type_Declaration;
>
> I prefer the first one, since anyone who knows
> anything about the structure of GNAT knows where
> Analyze_Type_Declaration is declared, and if you
> don't know, you can press the appropriate key in
> GLIDE and be bounced to the right package (or use
> gnatfind to quickly find the right package if you
> are not using an IDE).
>
> I really find the last one horrible. Lots of noise
> here that would greatly increaes the length of the
> code and add nothing.
>
> THe middle one is a bit of an oddity. It adds nothing
> to the readability, but I can see it being useful in
> a junk environment which did NOT have good navigation
> tools, since you can use the plain editor search
> capability to locate the renaming statement.

This is the most common reaction we receive when someone new enters our
software group where we have standards that require a 3 character mnemonic
as a part of all identifiers that are defined in package specs.  Usually
within a week of using this convention, they don't know how they ever worked
without it.

If I am reading some code that includes (using from the example above):

  SC3.Analyze_Type_Declaration;

I immediately know that this is a procedure that is defined outside of the
current package in something that is abbreviated as "SC3".  If the code
contained just:

  Analyze_Type_Declaration;

Then I would know that this is a procedure that is either defined locally or
in another package.  To find out which, I'll have to do some investigation.

I have found that when these conventions are followed I can move through
unfamiliar code very quickly without having to research each identifier.

FWIW
SteveD

>
> So in context I do not think this usage is
> necessarily a bad idea.
>
> Robert Dewar
>
>
> Sent via Deja.com
> http://www.deja.com/