> C64 BASIC has ingrained 1 evil in me. "goto" Atleast once a month I'll be working on some script and I'm stuck but a little voice in the back of my head will say: "a goto would fix this part you are stuck on!"
goto is perfectly fine if used right. Kernel C code tends to use a lot of goto, to consolidate return points and to clean up resources on the way. A long function with no goto to one common return point, or multiple staggered ones, is suspicious.
The problem that led to the famous paper was rather that goto was abused, used at places where "higher level" control construct like "for", "while" and so on would be better. Partly because the languages just didn't have any, like for example... C64 BASIC.
Yep, used a lot of goto's writing framework software that worked with CoreFoundation on Mac OS. We used it a lot in early Mac Toolbox framework code as well.
Often within the scope of a function we would need to allocate/create dictionaries, arrays, other objects requiring disposal. MacOS's CoreFoundation API often returned NULL when creation (or insertion, etc.) failed. The sane thing to do when you got an unexpected NULL was to "bail" from the function. But rather than return immediately, there was clean up code at the bottom of the function — code like "if stackDict != NULL {CFRelease(stackDict);}". So we often added a label (called typically "bail") just before the clean up code and would "goto bail".
goto is perfectly fine if used right. Kernel C code tends to use a lot of goto, to consolidate return points and to clean up resources on the way. A long function with no goto to one common return point, or multiple staggered ones, is suspicious.
The problem that led to the famous paper was rather that goto was abused, used at places where "higher level" control construct like "for", "while" and so on would be better. Partly because the languages just didn't have any, like for example... C64 BASIC.