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

261–270 of 601 posts

Re: Avoid Else, Return Early (2013)

#261

Post by RobertRoberts »

falcolas wrote: post #208
kstenerud wrote: post #167

Earlier quoted context omitted.

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

Why optimize for the lowest common denominator? I've seen both, and the reduction in vertical whitespace matters more to me than the readability to an untrained individual.

>Why optimize for the lowest common denominator?

You seem to be erroneously equating a coincidence with a preference.

Re: Avoid Else, Return Early (2013)

#262

Post by vortico »

tzahola wrote: post #249
vortico wrote: post #191

Earlier quoted context omitted.

Tell that to the APIs I work with, like POSIX sockets/Winsock, etc. You're suggesting that I wrap them all with RAII? That's ridiculous when you have hundreds of C types which are all used just once or twice. Using defer makes elegant/simple C-like code because it uses the C APIs directly and is nearly the same number of lines of code as a C programmer would write without using defer. I fail to see how "learning prop…

It's up to you to litter your code with these `defer` blocks. Although I'm a bit skeptical about POSIX sockets being such an obscure API that it's not worth creating a proper RAII container for them. (not to mention the pre-existing boost socket library) To each their own ¯\_(ツ)_/¯

A general rule in C++ programming is that time spent "perfecting" your code increases, the more difficult it is to change and maintain it, and the probability of using Boost approaches 1. Using Boost as a dependency makes your project very cumbersome for to users to compile by themselves.

I put perfecting in quotes, because I believe overengineered, verbose code is something that makes code worse for the reader, writer, and tester. This is why startups are able to accelerate faster than enterprise programmers while they are still able to do this sort of thing.

My point is that RAII is not for everyone, so much so that a popular modern language was developed which avoids it (Go) and includes `defer` instead.

Re: Avoid Else, Return Early (2013)

#263

Post by timoxley »

brandmeyer wrote: post #231
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…

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

These statements are strange to me as I personally see early returns as attempts as achieving exactly these goals. I guess people unroll logic in their head in different ways. "flat" to one may appear "nested" to another and vice versa.

Re: Avoid Else, Return Early (2013)

#264

Post by projektir »

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…

I'm waiting on the jury for Almost Always Auto...

Re: Avoid Else, Return Early (2013)

#265

Post by acjohnson55 »

Waterluvian wrote: post #141
timoxley wrote: post #78

Earlier quoted context omitted.

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.

...until you do.

That's the problem with antipatterns. It's impossible to remain alert to the edge cases, and then they eventually bite you in production. Better to lint them away. But it's difficult to convince people not to do something really convenient if they haven't gotten bitten yet.

Re: Avoid Else, Return Early (2013)

#266

Post by jorams »

bipson wrote: post #127
mden wrote: post #118

Earlier quoted context omitted.

Eh, all things equal, the less the number of lines the more readable.

I disagree. Consider the absurd example where every single statement is crammed into a single line. Not exactly readable to me? Sometimes more verbose code is more readable, and sometimes it is the presentation, and sometimes this is "superfluous lines", that increase LOC.

That's covered by "all things equal".

The argument against placing braces on their own line is that this:

    if (a)
    {
        print(a)
    }
conveys exactly as much information as this:

    if (a) {
        print(a)
    }
while taking up more space. The thing the brace tells you is already told by the indentation, so the brace is on a superfluous line.

Re: Avoid Else, Return Early (2013)

#267

Post by contravariant »

drawkbox wrote: post #75
tzahola wrote: post #72

Earlier quoted context omitted.

>Same way while/do/while is usually fades away, and if needed exit conditions. I couldn't interpret this sentence.

Edited, basically do not use while loops, if you do tread carefully and provide yourself an exit. You don't want to be the one that nukes the server.

Dijkstra's approach towards provably correct programs has changed my opinion on loops somewhat.

Among all types a 'while' loop gives the strongest mathematical guarantees. In particular it ensures a condition is true at the start of each iteration, and is false when exiting the while loop. Combining this with loop invariants leads to precise and straightforward to verify code.

Avoiding while loops to ensure an exit just seems to be sacrificing a lot of power in exchange for some pretty shaky guarantees that your loop will finish.

Although in the majority of cases where a while loop could be used you're simply iterating over some (implicit) data structure. In which case it's obviously better to make this explicit using a "for ... in" loop.

Re: Avoid Else, Return Early (2013)

#269

Post by kruczek »

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 evolve out of one liners.

> Same way braces go on the end of the method/class name to reduce LOC.

For me, these are exact opposites; the reason to not use one-liners is the same as the reason to put braces in separate line: both improve readability.

Re: Avoid Else, Return Early (2013)

#270

Post by josephv »

ivanhoe wrote: post #218
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.

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.
Post reply on HN