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.9 required=3.0 tests=BAYES_00,FROM_ADDR_WS
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 27 May 93 17:32:00 GMT
From: skates.gsfc.nasa.gov!bambam.gsfc.nasa.gov!nbssal@ames.arc.nasa.gov  (Step
he Leake)
Subject: Re: good software engineering (was: mixing integer and logical ops)
Message-ID: <27MAY199312323696@bambam.gsfc.nasa.gov>
List-Id: <comp.lang.ada>

Wes Groleau writes...
>>     I've always thought that one of the major advantages of Ada was
>>that it makes bad code look so bad that the author fixes it, often
>>before anyone else sees it.
> 

Robert I. Eachus writes:
>I think the reason is not that Ada makes it easier to spot "bad code"
>Rather, IMHO, it's that the "Ada community" has from the beginning
>had an attitude in favor of "pretty" and readable source code.  The
>C community on the other hand is unsuccessfully trying to change a
>culture that EXPECTS code to be unreadable.

I'll go with Wes; I've always found that if Ada makes me work to hard to do
what I think I want to do, there is usually a better way, or I don't really
want to do it. Put another way, if you find yourself writing inelegant Ada
code, take a step back and think the problem thru again. Maybe peruse the LRM;
some feature of Ada that you had temporarily forgotten about might jump and
suggest a better approach.

Stephen Leake	NASA Goddard Robotics Lab
internet : nbssal@robots.gsfc.nasa.gov