Timeline for Where did the notion of "one return only" come from?
Current License: CC BY-SA 4.0
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 11, 2023 at 10:54 | comment | added | Jim Balter | @TMN Spaghetti code wasn't about entry and exit, it was about languages with no structured constructs, so all transfers were via goto--or the equivalent: the FORTRAN IF statement took three labels, for whether the condition was < 0, = 0, or > 0. ALL code was necessarily spaghetti code. | |
| Sep 11, 2023 at 10:48 | comment | added | Jim Balter | "in the early days, most machines didn't have a hardware stack" -- machines still don't have a hardware stack. There's a register that is designated as a stack pointer, and some machines have instructions to push and pop stack frames but these are easily emulatable. The original PDP-11 C language compiler made use of auto-increment/decrement instructions on the SP register, but was easily ported to the INTERDATA and other machines without those. It wasn't until the C compiler was ported to the VAX that it made use special stack frame instructions. | |
| Feb 12, 2023 at 13:37 | comment | added | yeoman | I am in favor of early return :) I'm just not in favor of using it as an excuse for having super long functions 🙈 Of course, when refactoring a super long functions, early returns can help a LOT, just as you describen, @mtraceur | |
| Feb 10, 2023 at 16:28 | comment | added | mtraceur | This answer is great and I wish I had been taught this in school. I ended up eventually independently thinking through what guarantees we didn't have, what was harder, and what coupling/complexity was inherently created by unstructured jumping. And one of the worst parts of unstructured jumping is exactly this: the inability to predict where a function would return to (or which instruction in your code other code might jump to). Calling a function and being able to trust that it will return to your code instead of somewhere else is huge for enabling reasoning about code. | |
| Feb 10, 2023 at 15:56 | comment | added | mtraceur | @yeoman of course there are harms of readability which multiple return can cause. Some things are clearer when they're not factored as multiple returns. And I do think it's language-relative... For example, in a language like C where manual boilerplate is more commonly necessary for almost everything, multiple return is liable to come with duplication of boilerplate, which ends up being worse for readability than a single return. But I've seen more readability harm caused by bending the logic to a single return shape than by the freedom to choose the number of returns to best suit the logic. | |
| Feb 10, 2023 at 15:25 | comment | added | mtraceur | @yeoman early return has made almost every overly long method I've seen more readable. Words cannot describe the rage and desire for violence I have learned to feel when I'm done digging through that entire 700 lines someone else left behind (in order to refactor it) only to conclude "oh that's nice, I could have known in two lines up-front that if this condition is true then the remaining 698 don't apply, but that would've been too easy. So glad I had to load the entire 700 lines of behavior into my working memory and consciously bookkeep which possibilities just fall through." | |
| Jan 29, 2022 at 7:23 | comment | added | yeoman | Quote from my comment (actually the last sentence): Write short methods with a single responsibility and most code style issues will go away 😎 | |
| Jan 27, 2022 at 19:35 | comment | added | Andrew Henle | @yeoman Early return makes 700 lines long methods significantly less readable When are "700 lines long methods" ever "readable"? When you're complaint is, "That puts a worm into my 700-line pile of poo!", your problem isn't the worm. Nevermind more than implying that early return will always make code "significantly less readable" is, at best, an assertion without evidence that only takes one counterexample to prove false... | |
| Jun 12, 2020 at 12:08 | comment | added | yeoman | Early return makes 700 lines long methods significantly less readable, except when they consist of one switch statement or if-else chain, with one return per condition, where the early return is hard to miss. Just like being barefoot at home is a horrible idea if you've let you're overflowing sewers spill sewage all over your house for a week because meh 🤷🏼♂️ Write short methods with a single responsibility and most code style issues will go away 😎 | |
| Jun 12, 2020 at 9:58 | history | edited | kevin cline | CC BY-SA 4.0 | added 258 characters in body |
| Jun 12, 2020 at 9:53 | comment | added | kevin cline | Thanks Alexey. I seem to remember reading that paper when it was fairly new. It would have been about 1976. | |
| Jun 11, 2020 at 10:53 | comment | added | Alexey Romanov | I decided to check and there is something similar in cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF, page 28 (printed page number is 24). Not limited to functions. | |
| May 5, 2020 at 15:49 | comment | added | Quuxplusone | "Single Exit meant that a function should only return to one place" — {{citation needed}}. This answer could be greatly improved by a link to the place Dijkstra (or anyone else) is supposed to have talked about Single Exit with this particular meaning. As it is, it smells like a folk etymology to me. | |
| Oct 8, 2018 at 12:31 | comment | added | Caleth | @RickO'Shea My IDE lets me put a breakpoint on the final } of a function, and breaks there after any of the return statements is executed. | |
| Mar 10, 2018 at 21:00 | comment | added | kevin cline | @RickO'Shea: How long does it take to set a breakpoint? I'm not willing to complexify the code to avoid having to set multiple breakpoints in an IDE. I keep my functions short enough to fit on the screen, so it's no problem to set a breakpoint on all the returns. | |
| Mar 9, 2018 at 20:00 | comment | added | Rick O'Shea | That's nonsense. It has nothing to do with a specific language with the exception perhaps of assembly. A single return gives you a single point of return at the risk of stating the obvious. You can set a single breakpoint there, for example, and you're sure to get there. Now, if you want to have an assertion mechanism or pre-check of arguments at the head, for bad arguments, that preserves your single return point for the normal logic of your method, without cluttering on bad argument checks. | |
| Dec 6, 2017 at 19:51 | comment | added | kevin cline | @JivanAmara: Multiple returns from functions that allocate resources can lead to resource leaks. In C memory allocation happens frequently. Multiple returns from functions that allocate memory or other resources should indeed be forbidden. Memory management should be separated from computation. C# and Java have the same problem with non-memory resources. This was somewhat ameliorated by the introduction of the C# using statement and Java's try variables (or Lombok @Cleanup). | |
| Dec 5, 2017 at 22:12 | comment | added | JivanAmara | This doesn't just apply to assembly. There was also some research done at Microsoft (on C codebases) that found multiple returns contributed to higher bug frequency. See: amazon.com/Writing-Solid-Code-20th-Anniversary/dp/1570740550/… | |
| Jul 14, 2017 at 2:48 | history | edited | kevin cline | CC BY-SA 3.0 | deleted 8 characters in body |
| May 2, 2017 at 23:33 | comment | added | Justin R. | In addition to Algol, Scheme also supports continuations, and enables some pretty cool options, if the dev can accept the risks. | |
| Feb 24, 2017 at 15:35 | comment | added | Damian Yerrick | Is that an early form of the sort of continuation passing now seen in promise-oriented programming? | |
| Nov 18, 2015 at 10:52 | vote | accept | fredoverflow | ||
| Nov 29, 2012 at 0:44 | comment | added | acelent | Even though the op asked about the current interpretation of single return, this answer is the one with the most historical roots. There's no point in using a single return as a rule, unless you want your language to match the awesomeness of VB (not .NET). Just remember to use non-short-circuit boolean logic as well. | |
| Nov 22, 2011 at 21:15 | comment | added | kevin cline | @Mason: The original article on SESE was focused on provable code. Unrestricted branching creates a combinatorial explosion in possible program states. The use of exceptions could also complicate a correctness proof, if the catch clause accesses local variables that may or may not have been initialized in the main line of code. | |
| Nov 22, 2011 at 1:13 | comment | added | Mason Wheeler | So do exceptions violate this interpretation of Single Exit? (Or their more primitive cousin, setjmp/longjmp?) | |
| Nov 11, 2011 at 16:17 | history | made wiki | Post Made Community Wiki by Eugene - AmberPixels | ||
| Nov 10, 2011 at 22:08 | comment | added | sbi | @kevin: Yeah, but according to you this doesn't even mean anymore what it was invented as. (BTW, I'm actually reasonably sure that Fred asked were the preference for the current interpretation of "Single Exit" comes from.) Also, C has had const since before many of the users here were born, so no need for capital constants anymore even in C. But Java preserved all those bad old C habits. | |
| Nov 10, 2011 at 16:33 | comment | added | kevin cline | @TMN: in the early days, most machines didn't have a hardware stack. Recursion generally wasn't supported. Subroutine arguments and return address were stored in fixed locations adjacent to the subroutine code. Return was just an indirect goto. | |
| Nov 10, 2011 at 15:52 | comment | added | TMN | And don't forget spaghetti code. It was not unknown for subroutines to exit using a GOTO instead of a return, leaving the function call parameters and return address on the stack. Single exit was promoted as a way to at least funnel all the code paths to a RETURN statement. | |
| Nov 9, 2011 at 23:47 | history | edited | kevin cline | CC BY-SA 3.0 | added 17 characters in body |
| Nov 9, 2011 at 23:42 | history | edited | kevin cline | CC BY-SA 3.0 | Added END to Subroutine |
| Nov 9, 2011 at 16:43 | history | edited | kevin cline | CC BY-SA 3.0 | added 189 characters in body |
| Nov 9, 2011 at 16:32 | history | answered | kevin cline | CC BY-SA 3.0 |