GOTO considered useful?
On recalling the rationale behind the rule.
One of the great joys of spending enough time on the Su-Ha-Ri process is the opportunity to revisit no go zones. One of those infamous no go zones in the programming world, is the GOTO statement.
Completing Advent of Code in 2025, I had the opportunity to try it on for size again. Sometimes I come back to it, and it looks okay but the fit is a bit off. Or it fits good, but an outside observer would surely fail to see the appeal.
But sometimes, in deeply nested code, it fits good and looks good.
I often find myself writing loops that can end early. The "find the needle" style algorithms. There's probably three main strategies for signalling how the loop ended so you know whether to bail early or not:
- Su. Declare a bool outside the loop with a default value, set it within the loop if the non-default outcome occurred, and check the bool after the loop.
- Ha. Save a bool and just declare the loop index outside the loop. After the loop, check if the index got to the end or not.
- Ri. Goto baby!
Here is Ha vs Ri in a particularly deep, but not all together rare, case. Take a look. Notice how goto avoids the double if() break;? Do you think goto is justified in this case?
