Re: State machines and Goto's (was Re: Should internet support software be written in Ada?)

[stt@spock.camb.inmet.com (Tucker Taft)]

Theodore Dennison (dennison@escmail.orl.mmc.com) wrote:

: dewar@cs.nyu.edu (Robert Dewar) wrote:
: >Here is the basic issue with finite state machines. A normal picture
: >of a finite state machine is a spaghetti diagram with circles for
: >states and arrows for transitions.

One reason to prefer case statements over gotos for implementing
a finite state machine is that there is no danger of forgetting
the "goto" at the "end" of a state's code.  Using gotos instead
of a "case" statement opens up the programmer to the same kind
of bug as the notorious "missing break" in C/C++ switch statements.
You might just flow through to the state that happened to follow
in the text of the program, without intending to.  

E.g.:
        goto Initial_State;

    <<state_1>>
           blah; blah;
           -- oops, I forgot the goto.
    <<state_2>>
           ...

Versus:

     State : State_Enum := Initial_State;
     Next_State : State_Enum;
 begin
     loop
         Next_State := Uninitialized_State;

         case State is
             when State_1 =>
                  blah; blah;
		  -- oops, I forgot to set Next_State
             when State_2 =>
	        ...
	 end case;

	 if Next_State = Uninitialized_State then
	     Put_Line("Next_State not set");
	     Put_Line("Previous state is " & State_Enum'Image(State));
	     raise Program_Error;
	 end if;

         State := Next_State;  -- Advance to next state
     end loop;


Of course, you could also see the goto-based approach's capability 
of "flowing through" as a nice opportunity for optimization 
(that is presumably why "break;" is not the default in 
C/C++ switch statements).  However, I believe few would 
argue at this point with 20/20 hindsight (including the most 
die-hard C programmer), that the C/C++ default of "fall through" 
between switch alternatives was the right choice.

: Which is why people today tend to design using structure charts.

: >Please be clear, I am not saying that anyone who completely avoids 
: >gotos is incompetenmt, not at all. I am saying that it is wrong to think
: >that it is appropriate to visit this absolute rule on competent
: >programmers.

: I have now worked under 3 different Ada coding standards. Every one
: of them had a "no goto's" rule. Since I'm currently editing our next
: coding standard, perhaps someone could suggest a replacement rule? It
: should be very specific about what allowable and unallowable goto's
: are. We need something that our software quality folks can enforce.
: The rule can make NO assumptions about the competency of the programmer,
: as we won't find out the truth on that matter until it is too late.

Here is a half-serious ;-} suggestion:

How about requiring the programmer to write a short paragraph
in the comments, on why the goto was the most appropriate solution
for the given problem?  Require that the paragraph be no less than
20 words, and no more than 100 words long.  The net effect would
be to create a sufficient incentive that the programmer would have
to think hard before using a goto.

: T.E.D. (structured programming mafioso)

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.