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

Re: Avoid Else, Return Early (2013)

#141

Post by Waterluvian » Mon, Mar 26, 2018, 1:42 PM UTC

timoxley wrote: post #78

Waterluvian wrote: post #51

Earlier quoted context omitted.

JavaScript has the guard operator. It can really clean up your control flow when you know it's a guard operator and not just logical AND.

A big gotcha with `&&` as a guard in JS is that it can return any falsey typed value if you don't coerce the guard to a boolean. e.g. const check(cond) => cond && otherValue If `cond` is falsey, it returns `cond`. This means the function could return any of: `false`, `undefined`, `null`, '', `0` or `NaN`. This is a fairly common issue I see with React + JSX: {cond && } If `cond` is `false`, `null`, `undefined` or '',…

Good point. Good example. I imagine it works well in my cases but I haven't come across cases like your example where it breaks down.

Re: Avoid Else, Return Early (2013)

#142

Post by ajuc » Mon, Mar 26, 2018, 1:42 PM UTC

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…

This is like the 10 commandments. Good ideas mixed with stuff that is a matter of taste :)

If it was this simple we wouldn't be still arguing about coding styles decades after they were invented. I know few old programmers that I respect very much, and they don't agree about the perfect coding style, not even simple stuff, like braces in separate lines or not.

Re: Avoid Else, Return Early (2013)

#143

Post by djsumdog » Mon, Mar 26, 2018, 1:42 PM UTC

fouc wrote: post #119

optimuspaul wrote: post #108

Earlier quoted context omitted.

> Same way comments are extra weight that should only be in public or algorithm/need to know areas. Unless you are writing completely brilliant code your future self will hate you if you skimp on comments. Also self-documenting code is great, but intentions are not always clear to another person trying to figure out your code.

Only "brilliant" code ends up needing comments. Plain code organized into understandable methods (usually no more than half a page of code), with good naming for variables & method names reduces the need for comments. It's also easier to scan/read code if there's a minimum of comments in the way.

I agree with this. When dealing with a modern programming language, it's just easier to name your functions and variables in such as way that they're readable. It makes sense to document public functions using the language's documentation syntax, if you're writing an API.

I look back at a lot of my old code and even without comments, it's easy to follow the logic because I used sensible names and constructs.

Re: Avoid Else, Return Early (2013)

#144

Post by ajuc » Mon, Mar 26, 2018, 1:42 PM UTC

optimuspaul wrote: post #108

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 comments are extra weight that should only be in public or algorithm/need to know areas. Unless you are writing completely brilliant code your future self will hate you if you skimp on comments. Also self-documenting code is great, but intentions are not always clear to another person trying to figure out your code.

Comments that answer "what" are redundant. Choose your identifiers better.

Write good commit messages and comments that answer "why" are redundant too. Commit messages by their nature refer to the exact code that they refered to when they were written. Comments answering "why" after a few years are misleading anyway, because code changed around them.

Commenting public api etc is obvious, and most people do it.

Re: Avoid Else, Return Early (2013)

#145

Post by IshKebab » Mon, Mar 26, 2018, 1:43 PM UTC

zip1234 wrote: post #129

optimuspaul wrote: post #108

Earlier quoted context omitted.

> Same way comments are extra weight that should only be in public or algorithm/need to know areas. Unless you are writing completely brilliant code your future self will hate you if you skimp on comments. Also self-documenting code is great, but intentions are not always clear to another person trying to figure out your code.

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!

Re: Avoid Else, Return Early (2013)

#146

Post by scott_s » Mon, Mar 26, 2018, 1:44 PM UTC

vanderZwan wrote: post #134

fouc wrote: post #119

Earlier quoted context omitted.

Only "brilliant" code ends up needing comments. Plain code organized into understandable methods (usually no more than half a page of code), with good naming for variables & method names reduces the need for comments. It's also easier to scan/read code if there's a minimum of comments in the way.

There is a ton of code that only exists because of issues elsewhere in the code . This is the opposite of brilliant code: these are the dirty patchworks, the hacks glueing the whole thing together. Yet often these hacks are necessary, at least until some bug is fixed elsewhere. Clear, self-documenting code is great but it can't capture that holistic insight into what the whole program is doing. It can't capture conte…

Completely agreed. Put another way: the sentiment that code documents itself is only possible in purely logical systems with no edge cases or surprising consequences.

As an example, our code base has a comment which refers to our internal issue tracker which itself refers to this HN comment: https://news.ycombinator.com/item?id=9048947

Re: Avoid Else, Return Early (2013)

#147

Post by drakonka » Mon, Mar 26, 2018, 1:44 PM UTC

I used to prefer keeping a single return point in my methods, but over time this changed. Now I find myself returning as early as possible when there's an error or some other failed condition from which the method can't/shouldn't continue. For my hobby project I'm using Go and have found that it especially promotes this practice - it encourages me to handle errors early and often; if I nested all of the error-related conditions my methods would get very messy very fast.

Re: Avoid Else, Return Early (2013)

#148

Post by ebbv » Mon, Mar 26, 2018, 1:44 PM UTC

Good advice except for the last example which is brittle and unnecessary. If handleError() is ever changed this method could start returning values unexpectedly. Totally unnecessary and not a worthwhile "optimization" to save lines of code.

Re: Avoid Else, Return Early (2013)

#149

Post by moomin » Mon, Mar 26, 2018, 1:44 PM UTC

thomasahle wrote: post #30

moomin wrote: post #21

Earlier quoted context omitted.

I think the point OP’s trying to make is that reducing indentation levels makes code more readable. I don’t agree with him about removing the braces, though. That way madness lies.

This particular refactor (changing `if (err) { return ... }` to `if (err) return ...`) didn't actually reduce indentation levels though. It only reduced the number of lines.

Yeah, I’ll file that under “maybe don’t do that”.

Re: Avoid Else, Return Early (2013)

#150

Post by coldsauce » Mon, Mar 26, 2018, 1:44 PM UTC

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.