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

391–400 of 601 posts

Re: Avoid Else, Return Early (2013)

#391

Post by always_good »

josephv wrote: post #270
ivanhoe wrote: post #218

Earlier quoted context omitted.

In last 20+ years I've changed the coding style many times, usually to fit the current team style. And in my experience it takes a few weeks for the brain to rewire to the new style. First you hate it, and then you get used to it, and then you're like: wow it's great. Then you switch the standards for a new project and again, the same steps. It's just a matter of habit...

Pragmatic programming has lost. If you aren't a zealot about being pedantic, just move into the old-folks home.

I'd say it's the opposite. Code formatters are winning. It's becoming increasingly trite to bikeshed over formatting when projects are using code formatters.

Re: Avoid Else, Return Early (2013)

#392

Post by timoxley »

louhike wrote: post #2

I agree with much of the article (return early, errors management at the top, etc.). But won't returning a "wrong" value for the sake of one less line worsens the readability of the code? When I saw that, I imagined myself spending 10 minutes trying to understand why he does that. But maybe I'm not familiar with a JS best practice here.

The `err, result` function signature implies the function is an asynchronously executed node-style callback, which can never return anything anyway. Well, it can return something, but nothing internal reads it and there's no way for user code to access the returned value so return becomes only useful for short-circuiting.

Re: Avoid Else, Return Early (2013)

#393

Post by timoxley »

moomin wrote: post #149
thomasahle wrote: post #30

Earlier quoted context omitted.

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

what are the downsides

Re: Avoid Else, Return Early (2013)

#394

Post by jonny_eh »

true_religion wrote: post #373
lisper wrote: post #279

Earlier quoted context omitted.

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…

Python specific IDEs will smartly indent code upon copy and paste.

How does an IDE know if a given line belongs in an if block or not?

Re: Avoid Else, Return Early (2013)

#395

Post by monocasa »

jstimpfle wrote: post #322
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…

Wrong. You need to exit before resource allocations :-). And in general if you allocate resources in most functions you're doing it wrong. Need global resource managers. Stack variables should only very rarely be resource owners.

RAII works just as well for heap allocated objects as it does for stack allocated ones.

Re: Avoid Else, Return Early (2013)

#396

Post by platinumrad »

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…

Most functional languages also allow you to do something like this which is pretty much the same idea as guard clauses:

  foo 0 = 0
  foo 1 = 1
  foo n =
    ...

Re: Avoid Else, Return Early (2013)

#397

Post by nitrogen »

DanHulton wrote: post #319
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.

I've actually evolved a hybrid style in my personal projects - next line for functions/classes, same line for blocks. To me, it looks weird when functions don't have that extra line of space to set off their definition, but if/while/whatever aren't special enough to need that call out. That said, the most important factor is simple consistency. In my person projects, I have the hybrid style. At work, I use same-line-…

I think the Linux kernel style is similar. That was the first coding standard I somewhat adopted, but naturally have adapted to many others on different teams over time.

Re: Avoid Else, Return Early (2013)

#398

Post by RobertRoberts »

macspoofing wrote: post #369
RobertRoberts wrote: post #291

Earlier quoted context omitted.

I find it interesting how most of the comments about return early are based on experience. I had the same thing happen about 10 years in. I just got sick of the extra coding and long indented blocks. And just switched over one day. Why is this not taught from day one?

The problem is that for any rule you come up with there are cases where that rule is just too rigid and too inflexible. There are times where early return makes a ton of sense. Usually that's the case when you can derive the return value from a shallow interpretation of some input values (i.e. check preconditions) but still require more complex processing for other input values. In that case, return early, but constr…

Can't that be taught as well? (both rules, and exceptions to rules?)

Re: Avoid Else, Return Early (2013)

#399

Post by mnm1 »

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…

After twenty-five years doing this, the only thing I would say is that the style points you mention above are completely irrelevant and the points that refer to actually writing code mostly correct. Programmers that have been programming a long time and are skilled should know the difference between the two types of points and not confuse them as equally important as you do. Also not writing comments because the code seems obvious when you're first developing it is totally a rookie mistake. Codifying it in rules is a sign that the programmer simply doesn't understand how the human mind works over long periods of time. No code is self documenting after six months away from it. None.

Re: Avoid Else, Return Early (2013)

#400

Post by gknoy »

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.

> Only "brilliant" code ends up needing comments.

Often you have horrible complexity imposed on you from outside -- business rules you're implementing, etc, which are _not simple_. You can write code that encapsulates a lot of that, and even refactor it so you can see _what_ the code is doing pretty easily ... but it's often _very_ valuable to document in a code comment (docstring, JSdoc, etc) WHY it's like that.

Arguably, the comment is not to explain the code, in this case, but rather to explain the twisted bureaucratic logic you're having to implement, so maybe that still counts as "brilliant" code. ;)

Post reply on HN