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=0.8 required=3.0 tests=BAYES_50 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 6 Nov 92 22:48:51 GMT From: 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) Subject: Re: The Obfuscated Ada Contest (was Re: An admittedly biased ...) Message-ID: List-Id: 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_ - -------------------------------------------------------------------------------