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

[mcsun!sunic!nobeltech!dawe@uunet.uu.net (Daniel Wengelin)]

In article <1992Oct22.080735.19815@intrepid.com> gary@intrepid.com (Gary Funck)
 writes:

>1. Naming conventions that only computers can understand.  Something like
>   SCU_1_1_2_FCU_VAR (the 2167 disease), or ACU_CONTROLLER_X_AXIS
>   (the subsystem disease).  It seems that the readability of the
>   program has been sacrificed to the god of traceability.  .......
>
>2. The fully qualified never-use-the-use-statement syndrome, which
>   is a close cousin to the "local renames are clearer ... really".....
>
>3. The never-use-a-package-variable syndrome, whose close cousin
>   is the pass-the-world-via-procedure parameters syndrome.  On this....
>
>4. The Booch component syndrome.  I like Booch's books and OOP, don't ....
>
>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?
>

I would like to comment briefly on the issues raised by Gary. 

1. We have found no contradiction between readability and traceability.
   Maybe DoD2167-A  could impose problems, but the "subsystems disease"
   has not.

2. The "don't use use"-rule is applied in our company Ada Coding Standard
   (ACS). However, "localized use of use clauses can improve readability"
   and "Use your common sense and make sure that dependencies are easy
   to grasp for the reader".

3. Our ACS promotes information hiding and parameter passing.

4. I agree on the problem. The use of C.O.T.S. software is a very tricky
   area, especially in "live" real-time systems (as opposed to prototypes).


The bottom line is as usual _education and skill_, no matter the language
used or methods applied. However, concerning 2.-3. our experience is that
it is cheaper to maintain software that's on the abstraction side of
the "abstraction-performance tradeoff". It is true that parameter passing
is costly, but it is easier to flatten a structure to gain performance
than to create a structure to gain abstraction (understandability). This
could indicate that a language that promotes structure and allows
performance is preferred, rather than a language that allows structure
and promotes performance.

Concerning COTS sw, we have evaluated some with "less than perfect"
results. Correctness, performance, error handling, etc has to be 
ensured before the product is taken to use. Hence, I propose that
formal code inspections (conf. Fagan) are arranged for all COTS sw.


               Daniel W.


----------------------------------------------------------------
!    with Standard_Disclaimer;                                 !
----------------------------------------------------------------
!    Daniel Wengelin               ! E-mail: dawe@nobeltech.se !
!    Systems analysis and design   ! Phone : +46 8 58084000    !
!    NobelTech Systems             ! Fax   : +46 8 58081542    !
!    Naval Systems Division        ! Mail  : S-17588 Jarfalla  !
!                                  !         SWEDEN            !
----------------------------------------------------------------
! NobelTech: Winner of the -92 Ada Industry Leadership Award   !
----------------------------------------------------------------