4 ms·
I remember in my early days of programming one of the most errant pieces of advice I received was that every method should have one and only one return statemen
by mvdtnz 3y ago
I remember in my early days of programming one of the most errant pieces of advice I received was that every method should have one and only one return statement. Before I was told that, I had always cleanly handled edge cases at the top of the method like this article suggests, then handled the bulk of the logic.
I was young and impressionable so when a senior developer advised me of this nugget of "best practice" I spent the next couple of years writing awful code, jumping through hoops to mangle the logic in my methods such that they would only ever have a single return statement at the end.
Thank goodness I eventually awoke from that terrible practice. I still occasionally hear people espouse this, but not too often nowadays.
- eyelidlessness 3y agoI had a similar early experience. Amusingly, what broke me out of it was coming back to imperative languages after a good stint with Clojure. My initial instinct, coming back to an imperative language, was to try to return a single expression. You can do that, but it makes for rather unidiomatic code. Hewing more towards the idiom while trying to force functions towards a single return resulted in… a lot of statements, producing a lot of intermediate state. And it all gets much harder to follow. I’ve since embraced early edge cases and early returns, largely because it allows more idiomatic use of a functional style in an imperative context. And all of that makes the code a great deal easier to understand than it would be otherwise.
- nneonneo 3y agoI think the "errant advice" might originate with languages like C, in which an early return is an easy way to forget crucial deinitialization code, and where "goto"s can always be used to skip to the single exit point where all the deinitialization code is. In more sane languages, deinitialization happens automatically when leaving the stack frame, so following a "one return per function" rule is not necessary.
- clnq 3y agoOh yeah, I got that advice, too, in the early 00s. I thought it was quite strange then.
- benj111 3y agoThis is surprising to me. As a self taught hobbyist (crap) programmer that doesn't try too hard to make 'good' code. It nevertheless seems obvious to me that you'd want to deal with the errors first. I kind of disagree with the articles Pareto principle. 80% of programming is working out all the ways that things could go wrong, so it's better to think about those first, rather than getting into to juicy bits and leave the error handling for 'later' Maybe it was from my ASM phase, and wanting to avoid the extra branch? Or maybe it's because 'professional' programming is more cargo culting than we'd like to admit?
- Supermancho 3y agohttps://www.youtube.com/watch?v=I0Pt9Lf9JzQ https://www.youtube.com/watch?v=I0Pt9Lf9JzQ
- lttlrck 3y agoThat's a reaction to deep if-else's - and they can happen in the happy path, independently of error handling. I don't recall this requiring much code mangling though? It means defining the return variable at entry and set its value to the "failed" value (eg NULL or false) and return it once at the bottom. So you only touch the return on the happy path which reduces the number of error related else's, can reduce the need for guards too, it's consistent and you don't get caught out by early returns. I still use this when it suits the application.
- ptx 3y agoThis piece of advice (some claim) originates in FORTRAN [0], where apparently a function could be entered in multiple places and return to multiple places. Most other languages don't support these features in the first place, so the rule is nonsensical (because it's impossible to violate) and got misinterpreted. [0] https://softwareengineering.stackexchange.com/a/118793 https://softwareengineering.stackexchange.com/a/118793