I remember those days. I kind of vaguely thought I should consider this kind of advice, then I never did, and am glad of it.
There’s nuggets of something useful there. Big long conditionals with lots of logic statements can be hard, and turning subexpressions into variables can help. There are other patterns to try to avoid the difficulty of keeping track of large blocks of code that are run conditionally. Extracting to a method is a cure worse than the disease, but normal in Smalltalk.
Maybe it was also a reaction to a kind of coding practice that we no longer encounter. Deep spaghetti code was not uncommon, with flags being set, and lots of complicated chains of effect. Perhaps the result of people who were introduced to programming through assembly (which is no longer a common background). It’s a certain kind of code that is uncommon now (except maybe in embedded spaces and other low-level places where it’s common to get by with very few quality data structures).
I didn’t think to tag it historical but I submitted it with something like your latter paragraph in mind. It’s just interesting.
Isn’t that just good programming practice in general - to use the appropriate type of flow control construct (i.e. switch or exceptions) rather than putting everything into an if test? – ChrisBaugh
Without Dijkstra’s preeminence, the “considered harmful” formulation tends to put me off.
Deployed by mere mortals, use of the formulation Dijkstra popularized comes off to me as a suggestion of authority. And when I find neither Dijkstra’s authority or argumentative heft, the author’s case is almost always a disappointment.
I really dislike such advice. I remember in early 00s, lots of web developers adopting code without “else” and “early returns” and lots of other things that at the time were considered best practices. To be honest in many cases they just added friction to what would be an easier and more readable (if a bit more verbose) code.
That is ok. We don’t need to agree on that. To be honest, the most important thing is for a project to decide upon a style and follow it. I understand why multiple returns, for me they’re like guards, what I don’t like are “if” statements where what is clearly the “else” part is just left out of it because of an early return that might not be a guard. It is confusing, I know.
It makes it explicit and obvious that either one thing happens or the other, and never both. Sometimes that’s a valuable thing to communicate in your code.
I definitely prefer it to the common other pattern I see, which is if with a return at the end of the code block, then the else clause outside of the if.
terrible take
next up: for loops are smelly because you could lose the loop condition between the variable initialization and the loop update statement.
I remember those days. I kind of vaguely thought I should consider this kind of advice, then I never did, and am glad of it.
There’s nuggets of something useful there. Big long conditionals with lots of logic statements can be hard, and turning subexpressions into variables can help. There are other patterns to try to avoid the difficulty of keeping track of large blocks of code that are run conditionally. Extracting to a method is a cure worse than the disease, but normal in Smalltalk.
Maybe it was also a reaction to a kind of coding practice that we no longer encounter. Deep spaghetti code was not uncommon, with flags being set, and lots of complicated chains of effect. Perhaps the result of people who were introduced to programming through assembly (which is no longer a common background). It’s a certain kind of code that is uncommon now (except maybe in embedded spaces and other low-level places where it’s common to get by with very few quality data structures).
I didn’t think to tag it historical but I submitted it with something like your latter paragraph in mind. It’s just interesting.
Without Dijkstra’s preeminence, the “considered harmful” formulation tends to put me off.
Deployed by mere mortals, use of the formulation Dijkstra popularized comes off to me as a suggestion of authority. And when I find neither Dijkstra’s authority or argumentative heft, the author’s case is almost always a disappointment.
It was Gerard Salton who put that headline above Dijkstra’s letter https://dl.acm.org/toc/cacm/1968/11/3
Interesting! I always thought it was a bit more provocative than I’d expect from him.
I really dislike such advice. I remember in early 00s, lots of web developers adopting code without “else” and “early returns” and lots of other things that at the time were considered best practices. To be honest in many cases they just added friction to what would be an easier and more readable (if a bit more verbose) code.
I will die on the hill that early/multiple returns are more readable and usually result in simplified logic and so code that’s easier to follow.
That is ok. We don’t need to agree on that. To be honest, the most important thing is for a project to decide upon a style and follow it. I understand why multiple returns, for me they’re like guards, what I don’t like are “if” statements where what is clearly the “else” part is just left out of it because of an early return that might not be a guard. It is confusing, I know.
I like if/else.
It makes it explicit and obvious that either one thing happens or the other, and never both. Sometimes that’s a valuable thing to communicate in your code.
I definitely prefer it to the common other pattern I see, which is if with a return at the end of the code block, then the else clause outside of the if.