Monday, March 18, 2024

Goto is an Abomination

In response to Goto is Not a Horror, I must implore you witness:

func main() {
	var i = 0

	loop:
	i += 1
	if i > 10 {
		goto done
	}

	fmt.Println("Hello, world", i)

	goto loop
	done:
}

You might say, "that isn't fair, this is just bad code using bad practices". And you would be half correct.

Goto can be used for evil. And it is. Too often, goto is abused. But here's the thing: Goto can only be abused. The example is fair criticism because there is no "good" use case for it.

That was Dijkstra's point.

The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program.

It's too unconstrained, or "unbridled" as Dijkstra put it. This is still the case with the goto keyword today. And it will remain the case 56 years from now.

"It's not a problem anymore, that goto is gone," says this unusual justification for an abomination, as if Go supposedly fixed it. You've clearly read the original 1968 letter, but seem to have missed its 1987 follow up, "On a Somewhat Disappointing Correspondence."

The real myth is that somehow jumping around arbitrarily just magically stopped being an issue. As the 1987 paper alludes to, we have better problems to solve than your decision to avoid constraint.

You can write code without using the goto keyword at all and it will make your code less enigmatic. Try it sometime. Stop defending the indefensible.

As for me, I thought that by now professional programmers would have learned something.

No comments:

Post a Comment