Timeline for Where did the notion of "one return only" come from?
Current License: CC BY-SA 3.0
43 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 11, 2023 at 13:10 | comment | added | Jim Balter | SESE long proceded C and in no way is that where the notion comes from. | |
| Feb 10, 2023 at 19:30 | comment | added | mtraceur | @DonalFellows yes, but it is almost always possible to reduce logic into composable atoms of clear meaningful behavior that are short enough to fit even within 16 lines, let alone a modern screen. | |
| Jul 6, 2017 at 23:12 | history | edited | user22815 | CC BY-SA 3.0 | Improved grammar |
| Jul 6, 2017 at 21:55 | history | edited | Deduplicator | CC BY-SA 3.0 | added 28 characters in body |
| May 23, 2017 at 12:40 | history | edited | CommunityBot | replaced http://stackoverflow.com/ with https://stackoverflow.com/ | |
| Sep 7, 2016 at 7:52 | history | edited | sbi | CC BY-SA 3.0 | added 2 characters in body |
| May 22, 2014 at 15:40 | comment | added | sbi | @Mehrdad: I have answered to this years ago. | |
| May 22, 2014 at 9:34 | comment | added | user541686 | @sbi: Or you could just learn to do it right from the beginning so that you can structure your code readably without sacrificing the optimization or hindering debugging. I don't think I've ever seen the single-return convention harm code in some way, but I've definitely seen multiple returns rear their ugly heads when I'm trying to set a breakpoint to find what values a function is returning and inevitably end up missing one of the 4 returns in the function. | |
| May 22, 2014 at 8:49 | comment | added | sbi | @Mehrdad: 1. Write good, easy to understand, well maintainable code. 2. Fix the bugs. 3. Test whether it's fast enough. 3a. If it is, your done. 3b. If it isn't, profile and measure to find the (few) hotspots, and sacrify readability there. Only there. | |
| May 22, 2014 at 8:08 | comment | added | user541686 | You still want to do this with C++, because returning a single object lets the compiler avoid copies and moves entirely. | |
| May 19, 2014 at 14:46 | history | edited | Robert | CC BY-SA 3.0 | using in this case only works with objects implementing IDisposable |
| Jan 31, 2014 at 9:40 | comment | added | sbi | @Piovezan: "I can't see how introducing a local variable to be returned at the function's end necessarily leads to manipulating control flow through it." This is such a common case that I never thought I would need to show code doing that. Think a C algorithm, where all functions invoked return an error status. That is stored in a variable err, and if one function returns an error, all the others must not be called anymore. As for the rest: I won't even attempt to reply to that. | |
| Jan 28, 2014 at 17:06 | comment | added | Piovezan | ...want to call a log function or perform any other function/method call that is necessary in your flow). As a Java programmer, I find SE to be a valid extension to DRY and not a C convention to be blindly followed (defining variables at the beginning of the scope OTOH is yuck). Disliking SE to me suggests a tendency to avoid negative logic in control flow statements as well (if (!condition)) which may reflect a weakness in programming logic (negative logic statements should be harder to read, but not that much). | |
| Jan 28, 2014 at 17:06 | comment | added | Piovezan | This answer has a few non sequiturs. I can't see how introducing a local variable to be returned at the function's end necessarily leads to manipulating control flow through it. I can't find any other argument for the statement "SESE often makes code more complex" and can't see how cyclomatic complexity is increased without performing inappropriate control flow. I don't think freeing up resources is the only argument in favor of "single exit" as during maintenance you may need to add code right before the (preferably unique) return point, not necessarily for freeing up resources (you may... | |
| Jan 28, 2014 at 12:49 | comment | added | Piovezan | -1: You can reach "Single Exit" in the example with void f() { resource res = acquire_resource(); if( !f1(res) ) f2(res); release_resource(res); }. The logic behind the flow becomes even clearer. I think you should look for a better example. | |
| May 10, 2013 at 18:50 | comment | added | Jim Balter | " you basically have three options" -- Wrong. I use this: ftype f() { resource res = acquire_resource(); ftype ret = f_inner(res); release_resource(res); return ret; } ... then f_inner can do all the returning it wants. | |
| Nov 9, 2012 at 12:27 | comment | added | Giorgio | "So why do Java programmers stick to this?": I didn't hear this advice coming from Java programmers more often than coming from C++ or C# programmers. | |
| Nov 22, 2011 at 14:20 | comment | added | Donal Fellows | @sbi: More important for a function (procedure, method, etc.) than being no more than a page long is for the function to have a clearly defined contract; if it's not doing something clear because it's been chopped up to satisfy an arbitrary length constraint, that's Bad. Programming is about playing off different, sometimes conflicting forces against each other. | |
| Nov 21, 2011 at 23:57 | history | edited | phoog | CC BY-SA 3.0 | "to" not "too" |
| Nov 11, 2011 at 16:17 | history | made wiki | Post Made Community Wiki by Eugene - AmberPixels | ||
| Nov 11, 2011 at 8:52 | comment | added | sbi | @anon: SESE being a "cannon" is a wonderful Freudian slip. :) Anyway, any function that doesn't fit on one screen is too long. | |
| Nov 11, 2011 at 4:00 | comment | added | anon | Added from personal experience: SESE certainly leads to more complicated code- monsters such as the function that ends with 17 closing braces. Also, if you define the logic of an inner conditional, often there are very bizarre derivations of what is actually being checked from the mathematical sense. For a short function, fine SESE. If it doesn't fit on a screen, don't try SESE. Ultimately it's a style thing, used to be cannon, now seen as bad. 30 years on from now we'll look at a few "best practices" of today and think "that's terrible! what were they thinking?" | |
| Nov 10, 2011 at 15:26 | comment | added | riezebosch | @Xaade Definetely not using the 'var' keyword in C# I guess... | |
| Nov 10, 2011 at 15:14 | comment | added | sbi | @kevin: "Single Exit" is used nowadays the way I described it. It might well have started out for other reasons, but SESE advocates will certainly point out that "Single Exit" is necessary for proper resource cleanup. | |
| Nov 10, 2011 at 15:11 | history | edited | sbi | CC BY-SA 3.0 | added 18 characters in body |
| Nov 10, 2011 at 15:10 | comment | added | sbi | @Dave: Indeed, I should have known that! Will fix. | |
| Nov 10, 2011 at 14:55 | comment | added | Dave Van den Eynde | In C#, "using" is preferred over finally, to clean up resources that implement IDisposable. | |
| S Nov 10, 2011 at 7:40 | history | suggested | Sinthia V | CC BY-SA 3.0 | Changed assembler(tool) to assembly(language) |
| Nov 10, 2011 at 7:14 | review | Suggested edits | |||
| S Nov 10, 2011 at 7:40 | |||||
| Nov 9, 2011 at 22:14 | comment | added | kevin cline | -1: Sorry, SESE was not initially proposed to prevent resource leaks. In C, the best practice may be to pass a function pointer to a function that allocates the resource, calls the passed function, then releases the resource. | |
| Nov 9, 2011 at 21:36 | comment | added | user8 | @sbi The tangential comments were removed (note to everyone: any criticism that takes a dozen comments to flesh out needs to be its own answer), but can you improve your answer to incorporate the responses to the comment feedback you've received here? Anything important to understanding your answer shouldn't be buried here. | |
| Nov 9, 2011 at 15:03 | comment | added | Lee Louviere | I know a lot of the really bad habits that my place adheres to is mainly argued for using reading printouts. They argue that you can't see type in a printout, so prefixing with type (a, str, lp), is a good thing. They argue declaring variables at the top of scope is good because you know where to look when you read the printout. I'm wondering why if meetings are all that important, we don't have tablet machines instead of printouts. Maybe I'll suggest that at a later meeting.... over a printout. | |
| Nov 9, 2011 at 14:45 | history | edited | sbi | CC BY-SA 3.0 | added 773 characters in body |
| Nov 9, 2011 at 14:15 | comment | added | sbi | @Karl: Indeed, it is a severe shortcoming of GC languages like Java that they relieve you from having to clean up one resource, but fail with all the others. (C++ solves this problem for all resources using RAII.) But I wasn't even talking of only memory (I only put malloc() and free() into a comment as an example), I was talking about resources in general. I also wasn't implying GC would solve these problems. (I did mention C++, which doesn't have GC out of the box.) From what I understand, in Java finally is used to solve this problem. | |
| Nov 9, 2011 at 13:45 | comment | added | Karl Bielefeldt | Great explanation, just don't neglect that memory isn't the only resource of concern. There are also file handles, database connections, mutexes, etc. that last time I checked Java doesn't clean up as automatically as it does memory, and often needs to be more deterministic than memory garbage collection, i.e. you need to guarantee the resource is released when the function exits, not at some future garbage collection sweep. | |
| Nov 9, 2011 at 13:36 | comment | added | TMN | @sbi: Controlling execution with variables has largely been supplanted with polymorphism (no more 'catch-all' procedures controlled by magic flags). I really only see it in state machines anymore. | |
| Nov 9, 2011 at 12:35 | comment | added | Steven Jeuris | @sbi: true, but I have, and that's most likely our 'difference' (which doesn't turn out to be a difference) in opinion. See for example this Code Review question. It doesn't involve return but continue, but the same principle of unreadability due to early returns applies. | |
| Nov 9, 2011 at 12:31 | comment | added | sbi | @Steven: Of course you can demonstrate that! In fact, you can show convoluted and complex code with any feature that can also be shown to make code simpler and easier to understand. Everything can be abused. The point is to write code so that it is easier to understand, and when that involves throwing SESE out the window, so be it, and damn the old habits that applied to different languages. But I wouldn't hesitate to control execution by variables either if I'd think it made the code easier to read. It's just that I cannot remember having seen such code in almost two decades. | |
| Nov 9, 2011 at 12:02 | comment | added | Steven Jeuris | +1 for the explanation of explicit resource management, I never realized that. Although, I don't agree 100% with your updates. I can easily demonstrate you code with multiple returns (and have often experienced in practice) which degrades readability. | |
| Nov 9, 2011 at 10:10 | history | edited | sbi | CC BY-SA 3.0 | foixed formatting |
| Nov 9, 2011 at 9:45 | comment | added | R. Martinho Fernandes | @dan04 in Java 7 you don't even need the finally most of the time. | |
| Nov 9, 2011 at 9:41 | comment | added | dan04 | Right. In Java, cleanup code belongs in finally clauses where it gets executed regardless of early returns or exceptions. | |
| Nov 9, 2011 at 8:45 | history | answered | sbi | CC BY-SA 3.0 |