4 ms·

massively edited. very interesting, thanks for the comment They are literally goto end. It used to be done like that a lot actually. I suppose I could get rid

massively edited. very interesting, thanks for the comment They are literally goto end. It used to be done like that a lot actually. I suppose I could get rid of early returns with a variable and breaks, but is it worth it? Very good question. My claim is that yes it is tremendously worth it if you care about great code. The reason is because by introducing intermediate variables (or by using more the ternary operator ?) you will have a more expressive code, and then you will subsequently take better decisions when you will write/maintain/refactor it. And more importantly, you will refactor it because you can (how do you move code that's full of early returns?). At the end, your program will be much simpler and better (less bugs, faster, etc). Just try it in a big-enough program, you will not come back to the old ways, I think. My functions tend to be small enough for me to not run into problems with early returns. Very interesting. This point would require a live discussion. Many things are at play here, between over engineered object-oriented programs where everything is broken into little pieces that shouldn't (most of the time you should make a function when it's called twice, not because it represent a world object) and also, I'm not surprised you guys don't do bigger functions since you fill them with early returns. In clear, what I'm saying is: are you guys not able to write any big functions because of the early returns? I wasn't expecting that, sounds almost plausible. You end up breaking things up way too much, over engineering things and all just to avoid bigger functions because you can't have them because of the early returns? Very very interesting. Of course this is complete conjecture and certainly not true. Or is it? edit: it also depend on what you mean by worth it. In terms of market value, you will not be rewarded because the market the doesn't reward great code so much anyway, broadly speaking.

kd5bjo 7y ago
> They are literally goto end. So are a lot of other constructs: break is goto the end of the loop, continue is goto the beginning of the loop, the closing of a loop block is goto the beginning of loop, else is goto the end of the conditional, if is maybe goto the next else, and return (early or not) is pop from the stack and goto that address. The fact that a language feature uses a JUMP instruction does not make it necessarily evil; most of them do. Everything has both benefits and drawbacks which are often highly situational. You may find it easier to convince people of the problem with early returns if you limit the scope of the argument to a more specific context than “always”: it’s usually easier to make an argument for a concrete case rather than an abstraction, and then show how the same reasoning applies to a large class of situations.
solarkraft 7y ago
Thanks a lot for the elaborate reply. I do tend to break things up into small functions. Why is that over-engineering? It makes it easier for me to reason about my code. It also makes it easier to refactor sometimes, although of course you're now restrained by the function's construct, so it becomes more difficult to move things between functions. Do I understand correctly that you tend to make large functions because they're easier to refactor (and not returning early makes this easier)?

kd5bjo 7y ago

> They are literally goto end. So are a lot of other constructs: break is goto the end of the loop, continue is goto the beginning of the loop, the closing of a loop block is goto the beginning of loop, else is goto the end of the conditional, if is maybe goto the next else, and return (early or not) is pop from the stack and goto that address. The fact that a language feature uses a JUMP instruction does not make it necessarily evil; most of them do. Everything has both benefits and drawbacks which are often highly situational. You may find it easier to convince people of the problem with early returns if you limit the scope of the argument to a more specific context than “always”: it’s usually easier to make an argument for a concrete case rather than an abstraction, and then show how the same reasoning applies to a large class of situations.

solarkraft 7y ago

Thanks a lot for the elaborate reply. I do tend to break things up into small functions. Why is that over-engineering? It makes it easier for me to reason about my code. It also makes it easier to refactor sometimes, although of course you're now restrained by the function's construct, so it becomes more difficult to move things between functions. Do I understand correctly that you tend to make large functions because they're easier to refactor (and not returning early makes this easier)?