111–120 of 319 posts
I always encourage people to go read Dijkstra's GOTO paper, instead of just its title. It's a short and easy read, almost like a blog post. If you pay attention, you can see that the he was talking about spaghetti code vs structured code. It's better when the lexical structure of the source code maps to the execution structure. That is, if you know what is the current line being executed, you have a good idea of what…
I always encourage people to go read Dijkstra's GOTO paper, instead of just its title. It's a short and easy read, almost like a blog post. If you pay attention, you can see that the he was talking about spaghetti code vs structured code. It's better when the lexical structure of the source code maps to the execution structure. That is, if you know what is the current line being executed, you have a good idea of what…
The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. There's plenty of confusing and messy code around, but true spaghetti code that GOTOs all over the place and is nigh-impossible to follow has been extremely rare for a long time. I can't recall encountering it in the last 30 years. It easy to misunderstand what he was even talking about becau…
Forty years later, I'll still use a C goto if the situation warrants (e.g. as a getout from deep but simple if). Maybe because having long been an assembler programmer as well, goto's are part of the landscape (if/else is effectively a conditional and unconditional branch/jump).
Earlier quoted context omitted.
The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. There's plenty of confusing and messy code around, but true spaghetti code that GOTOs all over the place and is nigh-impossible to follow has been extremely rare for a long time. I can't recall encountering it in the last 30 years. It easy to misunderstand what he was even talking about becau…
> The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. Can't highlight this enough. The type of spaghetti code "goto considered harmful" was reacting to is basically impossible to create anymore, so anyone who didn't work on that type of code in the 80s or earlier probably hasn't seen it. And thus, is applying the mantra "goto considered harmfu…
If I look back it always comes back to naming and managing names of things. GOTO 100 is meaningless and one eventually runs out of meaningful names for GOTO labels. For me OOPs addressed the naming issue relatively effectively by using the data type as a namespace of sorts.
Earlier quoted context omitted.
The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. There's plenty of confusing and messy code around, but true spaghetti code that GOTOs all over the place and is nigh-impossible to follow has been extremely rare for a long time. I can't recall encountering it in the last 30 years. It easy to misunderstand what he was even talking about becau…
> but true spaghetti code that GOTOs all over the place and is nigh-impossible to follow has been extremely rare for a long time. Exactly! Recently I had the "pleasure" to work with some FORTRAN IV code from the early 60s, so I know what you mean. No functions/subroutines, only GOTOs. Even loops were done with labels. There is also a weird feature called "arithmetic IF statements" ( https://en.wikipedia.org/wiki/Arit…
There’s no good way to do a do…while loop in Fortran, other than a goto.
I was brought up on the GOTO statement in Fortran before the GOTO police outlawed it, so I'm quite familiar with its operation. Nowadays there's more consideration given to structured programming and that's a good thing but that doesn't necessarily mean that GOTO should never be used—and if it is then it doesn't mean the whole structure of one's program ought to be called into question. No doubt GOTO can be dangerous…
Earlier quoted context omitted.
This analogy implies that all other tools are 1000% safer, but they are not. In C it’s like pointing to a dusty corner behind a table in a room full of dirt. When was the last time you did “cut your arm” with goto specifically? What’s the count and time ratio to other issues? Were these also addressed as taboo or left as “experience earned”? Gotophobia in its largest part is just a stupid meme with no real world data…
Where do I imply other tools are 1000% safer? Even 30% safer is a win. 30% safer, 30% more readable, and 30% more productive would be even better. > When was the last time you did “cut your arm” with goto specifically? It's been a while since I've used C, and even longer since I've personally written goto statements. I do remember frequently getting tripped up on them right after undergrad. It's not friendly, and I d…
So it’s something bad from the undergrad past, no details. Must we take an advice based on that? I’m not sure I will.
I'm working in a C++ game engine project right now and it's constantly segfaulting. I can't imagine that setting register jumps manually in complex higher level code would improve my situation.
Neither would tabooing something based on weak or no evidence. “It doesn’t help here” and “we ban it and ostracize its use” are two different claims.
Earlier quoted context omitted.
I’d say this was more due to the case not being properly enclosed in brackets. Many people seem to really dislike using the brackets but this is what that gets you.
This is detected by -Wmisleading-indentation now.
Interestingly (or perhaps coming full circle), the bug reference by the GGP comment is also called out in the GCC 6.1 release notes:
> -Wmisleading-indentation warns about places where the indentation of the code gives a misleading idea of the block structure of the code to a human reader. For example, given CVE-2014-1266
sslKeyExchange.c: In function 'SSLVerifySignedServerKeyExchange':
sslKeyExchange.c:629:3: warning: this 'if' clause does not guard... [-
Wmisleading-indentation]
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
^~
sslKeyExchange.c:631:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
goto fail;
^~~~Earlier quoted context omitted.
> The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. Can't highlight this enough. The type of spaghetti code "goto considered harmful" was reacting to is basically impossible to create anymore, so anyone who didn't work on that type of code in the 80s or earlier probably hasn't seen it. And thus, is applying the mantra "goto considered harmfu…
If you have ever seen someone try an construct a bunch of nested IF statements with complicated conditional clauses you might think GOTO is not so bad. People have simply become better coders. There are also still GOTOs that are used in specific cases such as CONTINUE and BREAK - no labels required. If I look back it always comes back to naming and managing names of things. GOTO 100 is meaningless and one eventually…
Structured programming wasn't about eliminating jumps, it was about enforcing discipline in their use. The simplest way to do that is to eliminate raw GOTO from the language, but it's also possible to just be careful and use it wisely.
Drawbacks: additional variables Are we still chasing down the least variables possible in 2023?
If you’ve ever actually written more than toy C, you’ll know gotos are essential for resource cleanup and error handling. Even the famous goto fail was not a goto error, it was a block error (named because a cleanup statement `goto fail;` always executed because of a brace-less if). goto can be abused like any other language construct, but it’s uniquely useful and makes code more simple and easy to reason about when…