What is preferred: goto or if else()

[Kmax18]

This is a question about programming style, preferences, efficiency, and risk.

We are working on a state machine were multiple conditions are checked for a potential state transition. We are debating what is better, safer, more efficient, or simply more elegant: goto LABEL, or if else()  blocks?  The goto statement is simple, but if else() blocks are perhaps more robust in a team environment. See options 1 and 2 below. What do you recommend? Thanks!

Option 1: 

if (condition_1 true)
{
  [do something]
  goto END_OF STATE;
}

if (condition_2 true)
  [do something]
  goto END_OF STATE;

Option 2:

if (condition_1 true)
  [do something]
else if (condition_2 true)
{
  [do something]
}

[Andrew Neil · Accepted solution]

Surely, "goto considered harmful" has been a software development mantra since before the days of K&R ?

K&R themselves, in "The C Programming Language" say,

"Formally, the goto is never necessary, and in practice it is almost always easy to write code without it. We have not used goto in this book"

PS:

Edgar Dijkstra's paper, "Go To Statement Considered Harmful" - March 1968:

https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf

https://dl.acm.org/doi/10.1145/362929.362947

"For a number of years I have been familiar with the observation that the
quality of programmers is a decreasing function of the density of goto
statements in the programs they produce. More recently I discovered why the use
of the goto statement has such disastrous effects, and I became convinced that
the goto statement should be abolished from all "higher level" programming
languages (i.e. everything except, perhaps, plain machine code)."

(my emphasis)

From this transcription: https://www.jj5.net/file/2020-12-20-034127/dijkstra68/goto-considered-harmful.txt

[Andrew Neil]

Specifically, in the case of a state machine, a switch-case usually makes more sense - or something table-driven.

Generally, the whole point of a state machine is to avoid having to do a load of tests on separate conditions - perhaps you are confusing your event-detection with the state handling...?

[waclawek.jan]

> Surely, "goto considered harmful" has been a software development mantra since before the days of K&R ?

This has nothing to do with K&R, this is structured programming mantra. In fact, C is quite the opposite of structured programming (i.e. the Algol/PL1/Pascal lineage) environment from where this line originates.

And it was not Dijkstra who wrote that title. The original title of his article is different, and if you read into it, its spirit - we need a better replacement for goto, not that goto has to be abolished - becomes clear.

It was the recently deceased Niklaus Wirth (author of Pascal) who rewrote Dijkstra's original title to this provocative version; and he preached it since then, even considering addition of goto into Pascal to be his largest mistake.

While the switch/case construct is the canonical state machine solution, it has its limitations - mainly limitations of break (which is recycled for escaping from cycles, and is limited to a single level of nesting) and the implicit fallthrough behaviour, and the limitation of switch variable being integer and case variable being singular (although the latter is relieved through gcc extensions and IIRC newer C standard revisions), cumbersome "common end-play" for several cases, etc.. That makes goto an attractive alternative, and IMO acceptable if reasonable code hygiene is maintained.

JW

[Andrew Neil]

---

@waclawek.jan wrote:

This has nothing to do with K&R

---

I wasn't saying it was to do with them - just saying that it even predates them.

ie, that the issues have been very well-established for a very, very long time.

---

@waclawek.jan wrote:

acceptable if reasonable code hygiene is maintained.

---

The trouble is always in maintaining that hygiene! Especially as OP alludes to a team...

[Pavel A.]

> programming style, preferences, efficiency, and risk

The risk is not following programming style and preferences of your boss. Efficiency is a weak excuse for doing so.

Do not reinvent the wheel. It is already invented.

https://www.state-machine.com/products/qp

[Kmax18]

Hi Andrew, you are correct. I am using a switch block for the state machine. Each state is implemented using a case statement. This discussion about goto (or not) applies to the event checking within each state.

[Kmax18]

Pavel, thanks for the pointer to QP! I assume that you are actively using it. What is your main takeaway or recommendation. Regards!

[PGump.1]

Hi,

The fact is - GOTO is a complex statement, and those who treat it as a simple statement are foolish!

Example:

if (test) {
   int a;
   do something with a;
   goto label;
}
…
label:

What is going to happen here? Will the compiler compensate for my stupidity? Or will the end users be punished for it…

The above questions are rhetorical. If you don’t see the issue, then that is the issue…

Kind regards
Pedro

[Andrew Neil]

---

@Kmax18 wrote:

This discussion about goto (or not) applies to the event checking within each state.

---

Why are you checking events within each state?