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,MSGID_SHORT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 14 Dec 92 21:57:23 GMT
From: visicom!rlk@nosc.mil  (Bob Kitzberger)
Subject: Language pitfalls (was Re: FORTRAN bug)
Message-ID: <252@visicom.com>
List-Id: <comp.lang.ada>

Experienced C programmers have rules of thumb that they follow in order
to help them to avoid language "problems".  Ada programmers also have
rules of thumb to help them avoid language "problems".  If you were to
list the top five C rules of thumb, they'd be something like:

	1. Use conditional preprocessor directives in .h files to avoid
           multiple file inclusions (oops!  That's a C preprocessor rule ;-)
 	2. Always use curly braces in conditionals
	3. Be careful to use '==' when you mean it, instead of '='
	4. Always malloc one more byte then your array length for strings
	5. Always use 'break' in each switch case, unless you really mean it

The top five rules of thumb for Ada are probably something like:

	1. Don't get carried away using tasks as units of decomposition
	2. Don't use the predefined types; define your own types
	3. Use packages as units of decomposition.
	4. Use private types to hide implementation details
	5. Avoid the USE clause; consider RENAMES instead.

Note that the Ada rules of thumb are more geared towards programming
in the large, and reflect the fact that the Ada programmer spends less
time on annoying *run-time* syntax glitches (*), and more time on
encapsulation and decomposition issues.

	.Bob.

(*) Of course, Ada programmers spend more time with compile-time syntax
    errors than anyone else ;-)
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888