I use both if else and return, so in case I forget any the code still works as intended.
Avoid Else, Return Early (2013)
251–260 of 601 posts
Re: Avoid Else, Return Early (2013)
#252Programmers 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…
> Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so much easier to mentally parse code into blocks that they're worth every single LOC. I can't speak for anyone else but I'm not working on an 80x24 terminal anymore.
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 value in clang-format, clazy, etc) put the nail in the coffin of arguments against whitespace blocking. You can have an enforced uniform style throughout a project now, with no ambiguity, and in such contexts using whitespace as a block delimiter also has no ambiguity. It just takes advantage of formatting already being done to avoid redundant glyph use.
Re: Avoid Else, Return Early (2013)
#253Earlier quoted context omitted.
Totally disagree with you.... it's funny though that I read LOC as "level of complexity" not "lines of code". I've been writing code for 30 years and I think it's jarring when the braces are on the next line, so much easier for me to parse that when it's on the same line. But everyone is entitled to their own opinion.
python fans are going like "what are braces?"
but biased fans of both would argue that opening and closing a block in the same indent level (allman-style) is closer to python.
Re: Avoid Else, Return Early (2013)
#254Programmers 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…
> Same way you get joy deleting large swaths of code. This is the true sign of a programmer's transcendence. Specifically the irrational joy of seeing net negative LOC diffs. It's not about how much you can add. It's about how much you can remove without sacrificing correctness, functionality, and readability.
It's really code tetris
Re: Avoid Else, Return Early (2013)
#255Earlier quoted context omitted.
That's fine -- the Python folks have their own share of religious wars (starting with: tabs, or spaces?) :-)
As a C++ programmer I can assure you, I know plenty of individuals with very strong opinions on tabs vs spaces debate.
And spaces sub factions/opinions on 2 vs 4 spaces.
The correct answer is whatever the project is already using, unless it is new and then you luckily get to choose.
Re: Avoid Else, Return Early (2013)
#256As someone who has been working on a Scala codebase for the past year and who now forgets to use the `return` keyword in other languages, it still pains me when I see stuff like that first example in coding interviews. It doesn't help that the solution for my go-to problem has a bunch of places where you can return early...
Re: Avoid Else, Return Early (2013)
#257Programmers 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…
> Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so much easier to mentally parse code into blocks that they're worth every single LOC. I can't speak for anyone else but I'm not working on an 80x24 terminal anymore.
I see it the same way. It offers symmetry. The method name can be as long or short. At least the start of the code block and the end is easily visible since the indentation level remains same. Gives a sense of Python readability.
Re: Avoid Else, Return Early (2013)
#258Earlier quoted context omitted.
> Programmers with lots of hours of maintaining code eventually evolve to return early, [..] I agree with all your other points and I‘d even agree if you wrote return early makes code more readable but not that it‘s something experienced programmers do. Programming is still - to some degree - resource management. Inexperienced devs often miss that fact, because they are focused on memory management and believe they c…
I have doubts about whether "real" projects generally have these kinds of concerns. But even if they do, you can clean them up in a `finally`, or your language's equivalent.
Most languages with try/catch/finally don't have checked exceptions, so handling resource management in the those schemes is really brittle.
Re: Avoid Else, Return Early (2013)
#259Earlier quoted context omitted.
Cleaning up resources after use is not a question of performance, it is a question of correctness.
Choosing an environment that requires you to clean up resources instead of handling it for you is mostly a question of performance.
Not really, inlined RAII is just as fast as doing it yourself.
Re: Avoid Else, Return Early (2013)
#260Earlier quoted context omitted.
That's fine -- the Python folks have their own share of religious wars (starting with: tabs, or spaces?) :-)
Tabs, everyone can configure them however they want. :-)
I hate being able to configure stuff, I want other people to boss me around from anywhere in the world! Their opinion matters on my computer!