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]
}

[Pavel A.]

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

Please try and post this in some Linux mailing list. (especially kernel). 

[PGump.1]

Hi @Pavel A.

---

Please try and post this in some Linux mailing list. (especially kernel).

---

hahahaha, Nah, I'm looking for a quiet life... :)

You have my permission to do it.

BTW, it's not limited to Linux, it's everywhere. No doubt, plenty here too.

Kind regards
Pedro

[Pavel A.]

It's everywhere along with old plain C and pragmatic software engineering. Not dead yet. "If humans evolved from monkeys and apes, why we still have monkeys and apes?"

[PGump.1]

It’s “horses-for-courses”. I encourage multilingual software authoring.

Except when it comes to interpreted languages – hahaha

"Those who cannot learn from the mistakes of the past are destined to repeat them..."

Kind regards
Pedro

[Pavel A.]

@Kmax18 I don't use the QPI product actively, but picked some ideas from their learning materials. Knowing the right terminology and buzzwords helps when talking to customers and so on. My recommendation is learn, get inspired, try,  consume, and produce your own. It depends on the size and structure of your organization. In a small team, you have to be pragmatic and can afford it. In huge organizations, less so.

[Andrew Neil]

@Kmax18 and, of course, other State Machine tools/frameworks are available; eg,

https://www.iar.com/products/iar-visual-state/

I think I tried an evaluation of this years ago, and it seemed OK - if you can afford it.

And there are many tutorials online on how to implement by hand; eg,

https://barrgroup.com/blog/state-machines-event-driven-systems

[Kmax18]

Hi Andrew, thank you for your feedback. I also find thee articles by the Barr Group helpful. I plan to install and evaluate the open source QPI product. My work focuses on motion systems, where FSMs are important.

[Kmax18]

Thank you, Pavel. I appreciate your helpful comments. I plan to install and evaluate the open source QPI product, primarily as a hands-on learning tool.

[Kmax18]

Hi Andrew, following up on your question: of course the decision about a possible state transition is made within the current state. The condition (event) can be checked outside of that state (case block). Is that what you mean?

[Andrew Neil]

Yes.

Thus the "Event" that the State sees can be an enum -  so a switch or lookup table is probably the most obvious choice.