Re: Coding Standards & GOTO

[mheaney@ni.net (Matthew Heaney)]

In article <3426B51E.7296@lmco.com>, William.Dale.Jr@lmco.com wrote:


>As my charter for implementing a new Ada 95 standard is to have only 
>absolute rules that cannot be violated, 

You are setting yourself up for failure, as there is no such thing as an
absolute rule.

>I am forced to through out most 
>of AQ&S as mearly advice.  

Why the pejorative "merely advice"?  That's exactly what a coding standard
should be, advice on how to use language.

Read the section of OOSC-2 that discusses the difference between a rule and
a guideline.

>A major segment wants to use GOTO's ( visible
>objects in specs too ). I'd use the AQ&S right out of the box if I
>could. 

A "rule" comprises "guidelines," plus a list of the times when the
guidelines don't apply, ie

rule = guidelines + exceptions

For example, state your rule for the use of goto as follows:

Rule For The Use Of The Goto Statement

Guideline:
o Use higher-level control structures such as if, case, and loops, rather
than a goto.

Exceptions:
o Use a goto when you're mechanically translating code from another
language into Ada (example, converting from Fortran to Ada, or when you're
using a scanner generator that emits Ada code).

o Use a goto when you're hand-coding a finite state machine, such as a scanner.

End of Rule


And what's wrong with objects in the spec?  Have you read Ada.Text_IO
lately?  Again, this calls for guidelines for when to declare an object in
the spec, and when not to.  For example, when implementing a subsystem,
then an object shared among packages in the same subsystem can be declared
in the spec of a private package.

Also, a well-known object, used throughout the system, can be declared in a
spec:

package Targets.Objects is

   type Target_Array is array (Positive range 1 .. 20) of Target;

   The_Targets : Target_Array;

end;

What's wrong with that?


>Advice will be ignored, I'm sure, as all programmers know what's best
>for their code.  ;-) 

Not all programmers do know, and they appreciate the help.  Check out
Taligent's Guide to Designing Programs.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271