Avoid Else, Return Early (2013) • Hacker News Board

Re: Avoid Else, Return Early (2013)

#231

Post by brandmeyer » Mon, Mar 26, 2018, 2:36 PM UTC

arximboldi wrote: post #83

Mmm, I disagree. Influenced by functional programming, I prefer to use the style of: "keep all return statements at the same indentation level" in statement based languages. This way, it is easier to parse as an expression. For example: if (...) { let a = ...; return x(a); } else { return y; } Can be easily mentally factored into the pseudo-expression: return ... ? x(...) : y; It is easier to see what the side-effect…

> ... makes case analysis easier ...

> ...making the code look less complicated than it actually is...

> I'd rather emphasize the underlying declarative intent, the state machines, and pre/post-conditions.

So much this. The goal of refactoring code for readability is not to make it parse more like spoken language (ie, English). Its to aid in understanding and analysis. Having code layed out on the page in a way that mirrors the true control flow graph, makes understanding the CFG easier. Having a data flow graph that mirrors the control flow graph makes understanding the DFG easier.

Re: Avoid Else, Return Early (2013)

#232

Post by calibas » Mon, Mar 26, 2018, 2:36 PM UTC

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.

Nothing irrational about feeling joy over what is hopefully more succinct and efficient code.

Re: Avoid Else, Return Early (2013)

#233

Post by JKCalhoun » Mon, Mar 26, 2018, 2:37 PM UTC

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.

I agree. I'm not looking to increase code density. I leave empty lines between logical sections within functions to allow the code "breathe". It helps me parse my own code.

Re: Avoid Else, Return Early (2013)

#234

Post by tpush » Mon, Mar 26, 2018, 2:37 PM UTC

cesarb wrote: post #57

I have read somewhere else ( https://softwareengineering.stackexchange.com/questions/1187... ) that the "single exit" rule was not actually about having only one place where the function returns, but actually about having a single place where the function returns to . That rule seems to have been so successful, that no modern language I know of allows (the original definition of) multiple entry or multiple return (ex…

Multiple entry/exit points is the defining characteristic of coroutines(as described by Knuth.)

The functional equivalent would be (delimited) continuations and is extremely powerful (but potentially confusing in an untyped context.)

Re: Avoid Else, Return Early (2013)

#235

Post by makecheck » Mon, Mar 26, 2018, 2:37 PM UTC

This breaks down immediately because no matter how much is “handled” at the top, any one of the neatly-packed doSomething() and doMore() calls at the end can still fail and need handling. You can’t conveniently omit the mess that would be created for checking each of those.

“Errors in top if” is good advice but every “else” may need its own (indented) top “if”.

Indentation isn’t that nice but it is a very loud indicator of code becoming too complex, and a lack of indentation is a hint that an error might have gone unchecked.

Re: Avoid Else, Return Early (2013)

#236

Post by JKCalhoun » Mon, Mar 26, 2018, 2:38 PM UTC

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.

Yes, as long as you recognize where that line of obfuscation (LOO) is and stay just short of it.

Re: Avoid Else, Return Early (2013)

#237

Post by bunderbunder » Mon, Mar 26, 2018, 2:39 PM UTC

kabdib wrote: post #166

alunchbox wrote: post #157

Earlier quoted context omitted.

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?) :-)

These religious wars can largely be swept away with one simple, practical question: What is going to result in less noise in pull requests and the commit history, given that nowadays everyone uses a different editor with different configuration defaults, and is going to result in less time in pull requests squabbling over these kinds of formatting issues, given that nowadays everyone uses a different editor with different configuration defaults?

Tabs vs. Spaces has a fairly good answer that flows out of this way of looking at things. There is a counter-argument to that answer, but it is invalidated if you move toward conventions for argument lists and chained method calls that are also designed to limit noise in the source control system.

IMO, the argument about bracing also has a practical, non-religious answer once you start looking at your coding conventions this way.

Re: Avoid Else, Return Early (2013)

#238

Post by Grue3 » Mon, Mar 26, 2018, 2:39 PM UTC

In Common Lisp the syntax for early return is so ugly (```(return-from function-name result)```) that I use it very rarely. In general, it seems that in the languages that use implicit return (Lisps, Haskell, Rust?) having an early return is discouraged by design.

Re: Avoid Else, Return Early (2013)

#239

Post by weinzierl » Mon, Mar 26, 2018, 2:39 PM UTC

monocasa wrote: post #211

weinzierl wrote: post #200

Earlier 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…

That's one of the reasons I love RAII; all resources, memory and otherwise, are treated the same.

That‘s what I was thinking when writing my edit. The somewhat ironic thing is that C++ people could use early exits safely, but often don’t, while Java folks typically write early exit code when they really shouldn’t.

Re: Avoid Else, Return Early (2013)

#240

Post by drawkbox » Mon, Mar 26, 2018, 2:41 PM UTC

youngtaff wrote: post #175

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.

I'm with you on Allman style braces, prefer it and find them much easier to read. As everyone else seems to use K&R I've just had a adapt over time :-(

A pro maintains consistency though so that is good.

I like One True Brace Style (1TBS) with an uncuddled 'else', which has else/else if on new-line with the break before it (similar to Stroustrup K&R without any same line properties, one thing per line, no bracket-less statements) and setup the standard that way if I am designing it, but do Allman or whatever variant the codebase uses if it already exists.