The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Save your processor a billionth of a second of effort
Depending on the processor and the stack protocol you use to pass parameters and return values, you may find that you gain little to nothing.
Been there recently when I had to modify the 'traditional' call protocol of my old computer. Now it uses a second stack to pass parameters and return values, instead of inlining the parameters with the code for the call. Yuck, was way to close to self modifying code!. And I extended the address of the subroutine to 24 bits, so that I now can do bank switching in the calling protocol and call code anywhere in a 16 Mb memory space without the processor noticing anything. Not bad for a 40 year old 8 bit computer. If only there was a convenient way to access data anywhere in that memory space as well.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
after browsing this thread, finding it very hard to argue the case for it beyond "'cause I am, that's why!"
That's a good enough reason.
Me, I see adding returns where they fit as being more efficient (which it is), but unless you're doing something really intensive like editing high-res game graphics or video (where loops and if-blocks are hit, quite literally, billion of times), it won't make a difference that's human-noticeable, so stick to what you're happy with, and what makes your code easier on your eye, when you have to revisit it.
Tim Deveaux wrote:
If I were to use the multiple return paradigm I think I'd use multiple goto exit's instead. Which seems kinda uglee.
Every jump to a non-sequential line is a goto. Loops and if statements were invented to save you the trouble of writing endless goto lines, by adding them for you, in the background behind the code.
Think: What does return do that goto doesn't?
(Answer: it satisfies the anti-goto evangelists, by using a function named "return", which does nothing but call goto.)
Saying that the goto is unacceptable is saying that if and for are unacceptable. Never be afraid of using a goto in sequential code, as long as you use it intelligently.
E.g. exiting an if-block with a goto is usually fine, but exiting a loop with a goto often isn't (unless you're only using global variables, which... Yeah, no need to expound on that one).
I wanna be a eunuchs developer! Pass me a bread knife!
It's an old lesson I learned, probably from the days of assembly -- always have one point of return, mainly for consistent stack cleanup. I do rarely make an exception (to that rule) but usually end up making some other change that removes the if.
If you're doing parameter checking, as in your example, I tend to think it's better to throw an exception -- why should the function that's being called expect anything but valid parameters?
I've seen return sprinkled throughout a function as part of the flow control. I hate that. Sometimes I don't see the return, set the breakpoint at the end of the function, and then have to steps through from the top and realize some moron tossed in an early return. I'd almost rather they use a goto to the return, haha.
Personally, I look at code like that and refactor it into smaller functions that have no if statements, and the flow control occurs in a higher level function that doesn't do anything but call other functions based on conditions of previous functions or the data values. A lot more readable too when you separate out the flow control from the individual activities of each flow.
I think there are several issues at play here, the most important is one of consistency. If someone coming behind you can pick up on your style, much of the griping goes by the wayside. I am a strong supporter of early return - range checking arguments and the like. Where you get in to trouble is a 500 line function with nested returns - OR - so many levels of logic (to avoid nested returns) that it's screaming at you to re-factor it....
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Not messy at all. When reading through a method line-by-line
if SomeErrorCondition then
is actually pretty darn readable. When debugging, setting one breakpoint at the single return statement and then fiddling which branch of the nested if-statement was taken isn't really easier than putting a breakpoint at every return statement and see which gets hit.
I think that the Return statement should be dropped in any language,
for example look at Delphi (object pascal) they did not have a return statement until recently it seems. A function had to fill up a variable called Result, and because there was no return statement developers where forced to maintain a clean flow.
This is how it should be everywhere IMHO
The first person to use the term "clean flow" has the definition right to the term
My experience is that prohibiting return (and continue and break) easily ruins that "clean flow". The clean flow should be for the normal, standard, expected behaviour. If something unexpected occurs, or some special case appears, you should handle it (as far as required) and get out of there! You shouldn't clutter up the rest of the function code with error flags and statuses pertaining to a special condition that was handled much higher up, serving only to skip the rest of the function code. That messes up the rest of the function code.
"Then you should raise an exception", some says. That's just another way of returning prematurely; it does not ensure a single point of exit. Besides, the situation is not necessarity exceptional, it may be simply detecting that there is nothing more to be done. Program flow by exceptions is certainly no clean code flow.
Not sure what you mean
I never had to uses error flags and statuses for anything like this.
In my experience prohibiting return (and continue and break) never ruined that "clean flow" but always improved it. And without using stuff like ugly flags and statuses.
In our coding guidelines the return is prohibited, and since this was introduced we saw the time needed for maintenance and bugfixing dropped noticable.
And yes, exceptions are not to be used for program flow, that is very true.
I'm not sure which version of ReSharper you're using, but modern versions of Rider (which use ReSharper via IPC) would have recommended an early return with the ?. syntax you're proposing, granting you both the shorter expression and shallower nesting, which is good for readability.
Early returns do make the code easier to grok, if for no other reason than that it looks less like a giant chevron heading off into the distant future.
IMHO Early returns can simplify code and help remove 'blanket cases' rather than have deep nested logic which can be hard to read at first glance. Ive done this for getting on for 4 decades and it's never hurt me or the code ive written, and as for 'horribly messy code', if it's done right then i disagree
I like single returns but there are exceptions. Sometimes checking needs to be done at the start of a function. Checking that needs a couple of lines, not a single if. Sometimes there are 2-3 such checks. The single-return-rule would force the entire function to be indented 2-3 extra levels. Multi-return: zero extra levels.
"If we don't change direction, we'll end up where we're going"
Years ago I was working with people who insisted on single point of return and single loop termination, with no exception whatsoever. Both continue and break out of loops were "forbidden". These were also people who insisted on putting opening and closing braces on separate lines, and always enclose the body of an if in braces, even a single assignment (so the minimum line count for an if statement was four, eight lines for an if/else). In some code, opening and closing braces made up at least a third of the code lines.
I guess that made me stall. I got sick of vading through jungles and fords of little more than braces. Finding the end of a loop, or even a function, required you to leaf through pages by pages of code with minimal information content.
In my first programming course, one basic principle was taught: Always fit a function in a single page, so that you can overview all of it. Obviously, the main message was to choose a suitable abstraction level and factor out common sub-operations, but if an if/else costs you a minimum of eight lines, you can't build much abstraction (for the next level) in a single page!
So I use breaks, continues and returns, to keep the function logic together, not spread over multiple pages / screenfuls. If you immediately see where the loop ends, or you have all the returns on a single page, you will easily manage it. If you like to water out your code with tons of braces and elses and umpteen nesting levels, then you loose control over your returns. But that is exactly what returns and continues and breaks are meant to avoid.
Last Visit: 26-May-20 18:03 Last Update: 26-May-20 18:03