From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 25 Oct 92 12:25:30 GMT From: mcsun!sunic!nobeltech!dawe@uunet.uu.net (Daniel Wengelin) Subject: Re: The Obfuscated Ada Contest (was Re: An admittedly biased ...) Message-ID: <1992Oct25.122530.13415@nobeltech.se> List-Id: 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 ! ----------------------------------------------------------------