Usually we call this fail fast in the java world. There's a similar item in Java by Comparison on that: https://pragprog.com/book/javacomp/java-by-comparison#conten...
Avoid Else, Return Early (2013)
341–350 of 601 posts
Re: Avoid Else, Return Early (2013)
#342Earlier quoted context omitted.
That's one of the reasons I love RAII; all resources, memory and otherwise, are treated the same.
Downside is, now your cleanup code is spilled all over the codebase. And where it's implemented it lacks often the necessary context (from the location of use). So, it's often wrong or incomplete, or suffers from the type-for-single-usage syndrome. Yes, RAII works for the casual std::vector, but it's not a maintainable solution for general resources.
It's right next to the create code, not 'spilled all over the codebase'. And if you really want different behavior on destruction (which is _really_ rare IMO), you can pass a destruction strategy at object construction. If you don't know how you want to destroy something when you construct it, you need to take a step back and reexamine your architecture.
Re: Avoid Else, Return Early (2013)
#343Earlier quoted context omitted.
You could still write it as fun max(a, b) { if a > b { return a } return b } Not saying this is necessarily better or worse. The point I want to make is that your case isn’t special.
The earlier version is clearly better and more clear, but presumes a language where if is an expression (and the actual return keyword isn't required, though “return if ...” is nearly as good.) But if you are using a more imperative language where “if” is a statement, I think the merits of early return vs. use of an else clause are more balanced in this case.
In C style languages you have the ?: operator though, which is basically if as an expression.
Re: Avoid Else, Return Early (2013)
#344Earlier quoted context omitted.
That's covered by "all things equal". The argument against placing braces on their own line is that this: if (a) { print(a) } conveys exactly as much information as this: if (a) { print(a) } while taking up more space. The thing the brace tells you is already told by the indentation, so the brace is on a superfluous line.
> The thing the brace tells you is already told by the indentation Which is true, and of course begs the question: why do you even need the braces?
1) I frequently tell my diffs to ignore whitespace so I can see my structural changes without getting drowned in a sea of indentation changes when introducing new scopes. Not viable when diffing python.
2) I semi-frequently make indentation mistakes when resolving merge conflicts. In braced languages this is fixed by an autoreformat. In unbraced languages, I have to take a lot more care with merging, lest I end up in yet another lengthy debugging session ending in facepalms - or worse, check it in.
3) Redundancy in the face of typos and whitespace destroying mediums such as many pieces of web technology - comments sections, forums, etc.
Re: Avoid Else, Return Early (2013)
#345Earlier quoted context omitted.
python fans are going like "what are braces?"
The irony is that Python actually has open-braces, but they're spelled ":" instead of "{". And the syntax effectively enforces K&R style. When I write Python I end every block with a "pass" statement so that emacs can auto-indent my code properly. The "pass" statement thus effectively becomes a close-brace. It drives Pythonistas into conniptions, but I never have to worry about reverse-engineering a block of code to…
That's the bad part of not having braces.
If boundaries exist they need to be clear. One shouldn't have to count the tabs that make up the level of indentation.
Its already a challenge reading code. Counting invisible tabs makes it even worse.
Re: Avoid Else, Return Early (2013)
#346Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…
>programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom.
That's not true.
Sometimes, the code begs for an early return so you can focus on the meat of the method. Most times, that's not the case. Single return conditions should be the default, and you should have a good reason not to do the default. In Java, for example, if you also stick a 'final' on the uninitialized variable, you have very nice compiler check to enforce that every code-path initializes the variable once and only once. Sometimes that is also too strict for what you want to do, so you can break the rule, but you have to have a good reason.
>Same way braces go on the end of the method/class name to reduce LOC.
No. Just no. Not for that reason.
>Same way you move on from single condition bracket-less ifs. (debatable but more merge friendly and OP hasn't yet)
It's only debatable by people who are just used to it, or who want to minimize LOC for insane reasons. It's non-debatable in that it is a very common vector for bugs to sneak in. Over the last 5 years, there were probably as many bugs stemming from bracket-less ifs in our codebase.
>Same way you move on from heavy OO to dicts/lists.
You start introducing another common vector of bugs for a little flexibility. Sometimes that may be worth it. As a general rule, it's not worth it.
Re: Avoid Else, Return Early (2013)
#347Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…
"Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom."
I generaly don't like when one person says (declares) how experienced persons act, but in this case I have to confirm with myself, as I also "evolved" to it and I tend to program in isolation, so I am no influenced by others so much.
Re: Avoid Else, Return Early (2013)
#348Earlier quoted context omitted.
> (very large) side projects How big once you remove all the extra newlines?
LOL. This is the part of the Silicon Valley episode-bar-scene where the fight breaks out. Thank god OC didn't mention "Just like you move from tabs to spaces."
Well, he shouldn't have, considering it's the other way around.. :-)
Re: Avoid Else, Return Early (2013)
#349Earlier quoted context omitted.
I used Python enough that braces are completely meaningless to me in languages with them (ie, everyone else). Indentation is my mental delineation of code blocks. I just have to write these {} things all over the place because every other language is a gramatically bloated mess. The advent of automatic code formatting (and Python pioneered this in many ways with pep8, but even huge C++ projects are realizing the valu…
Let's see. The Unix indent utility was what, mid-1980s? GNU indent came out in 1989. Python was released in the mid-1980s. PEP-8 was released in 2001. Yup, Python clearly pioneered automatic code formatting. Nobody had done it before them...
Lisp pretty printing was available in February 1973 (http://www.softwarepreservation.org/projects/LISP/MIT/AIM-27...).
That document states Bill Gosper wrote one of the first pretty printers, but doesn’t give a date for it.
I would think it is much older, as writing a simple lisp pretty-printer is easy and reading lisp without autoformatting is “less than ideal”.
Re: Avoid Else, Return Early (2013)
#350Earlier quoted context omitted.
Tabs, everyone can configure them however they want. :-)
Until you need spacing that isn’t a multiple of your tab width then you’re screwed.
Why would you ever half-indent a block? For alignment you should of course use spaces (for whole alignment, not just the end, to be very clear).