Re: The Obfuscated Ada Contest (was Re: An admittedly biased ...)

[cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!wupost!crcnis 1.unl.edu!news.unomaha.edu!cwis!troj@ucbvax.Berkeley.EDU (Kevin Trojanowski)]

gary@intrepid.com (Gary Funck) writes:

>I'll close with a couple of questions:

>  - Are some/all of the above practices common to the Ada projects
>    you've worked on? If, yes, what's your take?  Did such coding practices
>    really improve understanding and maintaining the program?

In the group of people I work with, we have a myriad variety of styles, even
though we have a published "Ada standard" we're supposed to follow.  One of the
worst, in my mind, things people are doing in their code is preceding every
variable name with "The_".  Thus, you have statements assigning to record
componenets like this:  The_Box.The_Left_Side.The_Color

To me, that's NOT readable.  In addition, it's very annoying to have to type
when working on the code.  What's wrong with:  Box.Left_Side.Color or something
similar?

We also run into the case of variable names which are 30+ characters long,
or so it seems.  I agree that using variables such as X, Y, K, I, J, etc
can be hard to maintain, but so can code where the average identifier is
15+ characters long!

There are also compromises made in the "pass the world" notion.  Some 
packages do this, some do not -- we had to allow global variables in some
code, as we're dealing with X-Windows, and thus the Ada code isn't always
in "control".  X-Callbacks basically force you to use global variables.
There's a time and a place for everything.  Sometimes, globals are best,
sometimes passing as parameters is best -- to me, to try to force it into
rigid rules is a mistake, and produces hard to follow, and hard to maintain
code.

>  - Are the programming practices described above unique to Ada? 
>    I ask because I've seen a pattern in the "production" Ada code that
>    I've read; each program runs along the lines outlined above.
>    The C code that I've worked on had other problems, but long names,
>    rigid structure, and unnecessary levels of abstraction
>    weren't among them :-).

I've not seen them anywhere else...  In addition, we have a myriad collection
of one-line procedures; the tendency to produce them seems to come from the
programming ideas people are perceiving to go along with Ada.  While yes,
the compiler SHOULD optimize the calls into inline code, there's no
guarantee that it will.  In addition, one-line procedures are harder to follow
when tracing through the code to try to track down a problem.

>and a concern:

>  - If the only Ada programs that a new graduate/new hire/new Ada programmer
>    saw were by obscured "encrypted" naming conventions, rigid structure,
>    and poor performance, I'd be seriously concerned that Ada would
>    take the rap, when it is only the messenger.

>dissenting/confirming opinions welcome,

>- Gary

>-- 
>| Gary Funck  		    gary@intrepid.com  [uunet!uupsi!intrepid!gary]
>| Intrepid Technology Inc., Mountain View CA (415) 964-8135
>--


-------------------------------------------------------------------------------
-                                   "She had what it took: great hair, a      -
- Kevin Trojanowski                  profound understanding of strategic lip  -
- Internet: troj@cwis.unomaha.edu    gloss, the intelligence to understand    -
-      CI$: 70521,312                the world and a tiny secret interior     -
- US Snail: 1905 Thurston Ave, #8    deadness which meant she didn't care."   -
-           Bellevue, NE 68005                            -Douglas Adams      -
-                                                          _Mostly Harmless_  -
-------------------------------------------------------------------------------