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

281–290 of 601 posts

Re: Avoid Else, Return Early (2013)

#281

Post by hailk »

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.

I'll be flipping the point around by saying that if you are concerned about vertical whitespace reduction, you should probably look at the granularity of your files (debatable based on programming environment). Also we could be catering to the lowest common denominator by worrying about people with untrained symmetric sensibility.

Re: Avoid Else, Return Early (2013)

#282

Post by btilly »

zanny wrote: post #252
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 used Python enough that braces are completely meaningless to me in languages with them (ie, everyone else). Indentation is my mental delineation of code blocks. I just have to write these {} things all over the place because every other language is a gramatically bloated mess. The advent of automatic code formatting (and Python pioneered this in many ways with pep8, but even huge C++ projects are realizing the valu…

Let's see. The Unix indent utility was what, mid-1980s? GNU indent came out in 1989. Python was released in the mid-1980s. PEP-8 was released in 2001.

Yup, Python clearly pioneered automatic code formatting. Nobody had done it before them...

Re: Avoid Else, Return Early (2013)

#284

Post by reaperducer »

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 with you 100%. It's all about being able to skim through code to find what you want and understand structure quickly.

Allman is great for this. Though I'm a Whitesmiths guy, myself. Still, same idea.

/36 years of commercial coding here.

Re: Avoid Else, Return Early (2013)

#285

Post by jayvanguard »

wiradikusuma wrote: post #227

I guess I'm the minority here, I prefer "if else" with the happy path inside the if. Returning early gives me mental overhead of keeping the "elses" on my head, and doing it in Scala makes the code look more verbose.

I don't think you're in the minority. Whenever possible the happy path should be inside the if. The article seems to imply otherwise but on re-read I think he is just building the case for putting the simple, quick pre-condition type handling up front which generally removes the need for the if/then (which I agree with).

For complex methods with branching logic you want prominently displayed, you'd end up with:

def myfunction(args) {

  // check preconditions, return early

  if (x) {
    // happy path
  } else {
    // less happy path
  }
}

But if the else just contains a bunch of error handling you always have the option of wrapping it in a handler method and putting it near the top in a on-liner.

Re: Avoid Else, Return Early (2013)

#286

Post by jwilk »

tom_mellior wrote: post #216
kabdib wrote: post #166

Earlier quoted context omitted.

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

Do they? All the Python folks I've ever seen express an opinion on style have said "follow PEP 8". Unsurprisingly, PEP 8 does have a rule for tabs vs. spaces: https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces (spaces, of course)

As a data point, I don't follow (all of) PEP-8.

But tabs vs. spaces is indeed a bad analogy, because of course it's 4 spaces. ;-P

pycodestyle, the Python style checker, has a few checks disabled by default (because there's no consensus they're good ideas), and even some mutually exclusive ones:

https://pycodestyle.readthedocs.io/en/latest/intro.html#erro...

Re: Avoid Else, Return Early (2013)

#287

Post by vortico »

yorwba wrote: post #247
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…

You could use a std::unique_ptr with a custom deleter: http://en.cppreference.com/w/cpp/memory/unique_ptr

This is a reasonable suggestion since the code isn't too bad.

    std::unique_ptr> p(new Foo, [](Foo* p) {
        if (p) destroyFoo(p);
    });
    // initialize Foo and set to NULL if failed
It increases complexity a bit because you no longer have a simple pointer, and you can't allocate on the stack anymore (my example should have declared `Foo foo;` with `destroyFoo(&foo)`, sorry for typo.)

Re: Avoid Else, Return Early (2013)

#288

Post by RobertRoberts »

defertoreptar wrote: post #224
jrimbault wrote: post #91

Earlier quoted context omitted.

>braces go on the end of the method/class name to reduce LOC You could argue the placement of braces with lots of valid arguments both way, but this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces...

Let's say we can see 30 lines on our screen and the average function takes 5 lines with OTBS. That means we can see 6 functions at once with OTBS and 5 with Allman. That makes a difference at least in my case.

Not being a pest here, but how often are you comparing more than 2 functions at a time? I can't say that I have ever dealt with code in over 20 years where I had to deal with more than 2 functions at once.

Maybe I am mentally disabled, but I can only focus on one logical task at a time. Can other programmers multi-task their coding?

Re: Avoid Else, Return Early (2013)

#290

Post by brann0 »

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 always adapt to the style used in the project I land. I can understand people liking one over another but to reach holy wars levels of disagreement about this kind of subject is something I don't get.

Same goes to spaces vs braces, editor wars, etc.

Downside: my projects are usually a bit of a mess with mixed indentation styles :D

Post reply on HN