Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoid Else, Return Early (2013)

blog.timoxley.com

Post reply on HN
Print view View original

161–170 of 601 posts

Re: Avoid Else, Return Early (2013)

#161

Post by YCode »

IshKebab wrote: post #145
zip1234 wrote: post #129

Earlier quoted context omitted.

The problem with this is maintaining comments. If you are using a compiled language or even linting, code that is part of the codebased is checked by a machine at least in a cursory way and the code that is there is what runs. The comments are not guaranteed in any way to pertain to the code that is in the repo and there is not a way for a computer to check the meaning of the comment to make sure that it was updated…

> The problem with this is maintaining comments. That's like saying "the problem with healthcare is that it costs money". Of course comments can get out of date. The solution isn't to throw them out!

"The problem with installing a roof on your house is one day it can be blown off."

Re: Avoid Else, Return Early (2013)

#162

Post by arghwhat »

foobarchu wrote: post #102
arghwhat wrote: post #79

Earlier quoted context omitted.

I would argue that it is by no means more convoluted. It is quite clear and concise. All of the following are equally readable: if (x > y) { return x; } else { return y; } if (x > y) { return x; } return y; return (x > y) ? x : y; The logic would be convoluted if you are going through extra hoops in order to write your logic like this, making the flow of the application unclear. For some things, an else branch ends u…

I think it's only clear and concise looking because of the achilles heel of this entire thread: terse examples. As soon as you need to do more than a single line of work, the else'd version becomes far more readable (due to superior indentation and clearer guarantees of what happens when). If it's a single line of return in both branches, then a ternary expression is usually going to be ideal instead.

We can definitely agree that the examples are too simple to present any readability issues with any method of writing them short of an IOCCC entry.

I do not agree with the conclusions you draw at all, but it is hard to continue the discussion without examples. There are definitely cases where an else clause is the natural choice, but I believe that these are in the minority.

Re: Avoid Else, Return Early (2013)

#163

Post by Quarrelsome »

3pt14159 wrote: post #116
Quarrelsome wrote: post #85

Earlier quoted context omitted.

> Same way you move on from heavy OO to dicts/lists. OO is better if the objects tell a story in a way that ProviderStrategyDataFetchers fail to do so and are effectively just wrappers for data structures. If you go pure data structure without story you just end having to add comments to explain purpose. The comments are the classes.

I agree with both you and the OP. OO where necessary, lists and dicts where things are simple. You can always take a list of strings and turn it into a list of objects. But going the other way is harder because you have to refactor anything that depends on them.

The concern is when you encounter a list of very dense transforms between different data structures without anything informing you as to the purpose or even reason for these operations. Is it _just_ to build the output, are there critical side effects in the process? Are the apis just so bad that all these operations _need_ to be performed or is just pure 100% required processing? Method names help somewhat if people are adverse to objects. All that concerns me is that much modern functional code often becomes very dense transforms with little narrative to inform the reader.

Re: Avoid Else, Return Early (2013)

#164

Post by sifoo »

SideburnsOfDoom wrote: post #45
spdionis wrote: post #23

This refactoring is so simple and obvious I don't even understand why some people don't write like this by default. I've had colleagues comment my PR on my "failed validation, return early" code saying "we generally strive to maintain one single point of return". I mean, why would you want only one return even?

> I mean, why would you want only one return even? Some other comments here discuss resource cleanup issues that can creep into C code with early return. If you're not coding in C, then more likely it's pure cargo-cult.

Are you saying that closing files is now a cargo-cult thing to do? There are plenty of resources that are more important to clean up than memory. This has nothing to do with C.

Re: Avoid Else, Return Early (2013)

#165

Post by dudul »

coldsauce wrote: post #150

I guess this makes sense when programming in an imperative paradigm. Scala, for example, has a completely opposite convention. Most of the scenarios he describes are usually things that would never occur in a functional paradigm.

Agreed. I've been writing functional code for almost 10 years now and I fail to see any situation in which I could apply this.

Functions are rarely longer than 10 lines, there is no explicit return statement, just a short sequence of data processing and that's it.

Re: Avoid Else, Return Early (2013)

#166

Post by kabdib »

alunchbox wrote: post #157
optimuspaul wrote: post #111

Earlier 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?"

That's fine -- the Python folks have their own share of religious wars (starting with: tabs, or spaces?) :-)

Re: Avoid Else, Return Early (2013)

#167

Post by kstenerud »

optimuspaul wrote: post #111
Merad wrote: post #106

Earlier quoted context omitted.

> 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.

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.

I've done a number of informal tests on friends and family over the years regarding brace placement, and it's always been the same: For someone with NO experience programming (i.e. looking at what to them seems like a bunch of gobbletygoop - and what's a "text editor"?), adjacent braces make it appear more readable than same-line braces.

It's only people who cut their teeth on adjacent bracing that find it more readable.

Re: Avoid Else, Return Early (2013)

#168

Post by redleggedfrog »

Merad wrote: post #106
drawkbox wrote: post #65

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. 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.

Yeah, I agree with the list above except for that one. It always bugged me that idiomatic Javascript was like this. I guess Javascript just bugs me in general, though, too.

Re: Avoid Else, Return Early (2013)

#169

Post by icebraining »

koolba wrote: post #95
drawkbox wrote: post #65

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. 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.

A story about that from the early Apple team: https://www.folklore.org/StoryView.py?project=Macintosh&stor...
Post reply on HN