Public Group

# Is this a bad use of GoTo?

This topic is 2686 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

[source lang="vb"]
Function fsmHeater()
Dim Timer As Integer 'Initialize
State0:
Off (oHeater)
Off (oAlarm)
'---
WaitFor(Temperature() < 84)
State1:
On (oHeater)
Timer = GetmS()
'---
Select Event
Event Temperature() > 85
GoTo State0
Event GetmS() - Timer > 6000
GoTo State2
EndSelect

State2:
Off (oHeater)
On (oAlarm)
'---
WaitFor(Input(iResetButton))
GoTo State0
End Function
[/source]

Is this a good use of GoTo? This code is supposed to mimic a FSM. Personally, I see nothing wrong with it. Given the function is pretty short. But I wonder if this approach should be avoided: because of a better solution, or just because GoTo is the spawn of evil itself.

A snippet from page:

Notice that when an event match happens the line of code following the event condition is executed. In this program that is a GoTo. In many circles GoTo is considered to be bad programming. Not so in coding FSMs; GoTo allows you to move from place to place in the code in a way that echoes how the state diagram transitions from place to place. [/quote]

##### Share on other sites
Depends on how WaitFor is implemented. I might be more inclined towards more of an event driven model because it's easier to modify/extend/test, but this is pretty clear and nice (despite my disdain for all things goto).

##### Share on other sites
You could also use the equivalent of a switch statement
warning heavy sudo code

 void fsmHeater() { bool AreWeDone = false; int State = 0; while(AreWeDone == true) { switch (State) { case 0: { Off (oHeater) Off (oAlarm) '--- WaitFor(Temperature() < 84) }break; case 1: { On (oHeater) Timer = GetmS() '--- Select Event Event Temperature() > 85 State = 0; Event GetmS() - Timer > 6000 State = 2; EndSelect }break; case 2: { Off (oHeater) On (oAlarm) '--- WaitFor(Input(iResetButton)) State = 0; }break; } } }

##### Share on other sites
Personally, I don't like it. I was going to suggest pretty much doing the same thing as yewbie did. If you have a game loop then all you should need to do is set a variable to the state you want and when the next loop comes around the initial switch (select) statement will catch the new state and do what you wanted; therefore the goto statements are not needed.

I just don't like goto statements... sorry

##### Share on other sites
off-topic: wow. the editor is really bad. I hope this new forum upgrade fixes this.

on-topic: that's not bad either. doesn't look much different from the GoTo really.

##### Share on other sites
In this instance, given the function in question it's fine.

However given that most FSMs are generally written in a 'do something, optionally set next state, return to caller' manner a goto is unlikely to be a good match in the majority of cases when using/writing a FSM.

##### Share on other sites
Also, I just read that first page of the link you provided on FSMs and I have to say I completely disagree with the following statement:

Notice that when an event match happens the line of code following the event condition is executed. In this program that is a GoTo. In many circles GoTo is considered to be bad programming. Not so in coding FSMs; GoTo allows you to move from place to place in the code in a way that echoes how the state diagram transitions from place to place.[/quote]

You can accomplish exactly what you need to do in a Finite State Machine without ever using a goto statement! But then again, what do I know... I'm a noob at all this stuff too

##### Share on other sites

Is this a good use of GoTo? This code is supposed to mimic a FSM. Personally, I see nothing wrong with it. Given the function is pretty short. But I wonder if this approach should be avoided: because of a better solution, or just because GoTo is the spawn of evil itself.

FSMs have been traditionally implemented using a switch statement (see above).

The reason lies elsewhere. A FSM is a graph, which can be represented using a matrix. Since all but the most trivial FSMs contain considerable number of states and might be machine generated, using state and action tables is by far the simplest way to implement them.

It has less with style but more with pragmatic approach.

There is another benefit of using state as external variable. One state advancement can act as generator or yield operator. Or put differently, if you call your state machine via some function "advance()", it will move one state, then return, allowing to take action, rather than just having to modify the internals of FSM during development.

In language parsers there is usually nextToken() function, which is a state machine that will return in the middle of processing. Such workflow is typically not possible using gotos.

For fixed FSMs, such as interpreters or VMs, gotos will often be machine friendliest and fastest way to implement them. They are used by JS VMs, for example. They are simply a natural fit, since a FSM is nothing but jmps and gotos translate to those directly.

##### Share on other sites
It's been a looooooooonnnnnnnnggggggg time since I have used a basic derived language, so excuse my ignorance, but does BASIC have a viable switch statement?

##### Share on other sites

It's been a looooooooonnnnnnnnggggggg time since I have used a basic derived language, so excuse my ignorance, but does BASIC have a viable switch statement?

Yes and I believe it's a "select statement" in basic

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

(You must login to your GameDev.net account.)

• 28
• 16
• 10
• 10
• 11
• ### Forum Statistics

• Total Topics
634111
• Total Posts
3015560
×