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

211–220 of 601 posts

Re: Avoid Else, Return Early (2013)

#211

Post by monocasa »

weinzierl wrote: post #200
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…

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

Re: Avoid Else, Return Early (2013)

#212

Post by vortico »

heavenlyblue wrote: post #89
vortico wrote: post #63

This also works well with a C++ `defer` helper. #define CONCAT_LITERAL(x, y) x ## y #define CONCAT(x, y) CONCAT_LITERAL(x, y) template struct DeferWrapper { F f; DeferWrapper(F f) : f(f) {} ~DeferWrapper() { f(); } }; template DeferWrapper deferWrapper(F f) { return DeferWrapper (f); } #define defer(code) auto CONCAT(_defer_, __COUNTER__) = deferWrapper([&]() code) Example of usage: { Foo *foo; if (initializeFoo()) {…

So with this, you literally had just thrown away the whole concept of RAII...

See my response to the sister comment

Re: Avoid Else, Return Early (2013)

#213

Post by jasonmaydie »

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.

it's not just about in app resources. This could also affect external resources.. like not cleaning up temporary files because a future maintainer returned early and left some critical data behind.

Re: Avoid Else, Return Early (2013)

#214

Post by loup-vaillant »

Turing_Machine wrote: post #139
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...

"this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces..." It's not really a valid reason. Unfortunately, there are still a lot of people who think LOC is a valid metric.

Here's an extreme, yet very real example: mandatory Doxygen comments on accessors:

  /**
   * Get the foo
   *
   * @return the foo
   */
  int getFoo();

  /**
   * Get the bar
   *
   * @return the bar
   */
  float getBar();

  /**
   * Set the foo
   *
   * @param foo the foo
   */
  void setFoo(int foo);

  /**
   * Set the bar
   *
   * @param bar  the bar
   */
  void setBar(float bar);
Compare with what any sane project would do:

  int   getFoo();
  float getBar();

  void setFoo(int   foo);
  void setBar(float bar);
Multiply that by a dozen such attributes, and what should fit on a single screen spans now hundreds of lines. What you could see at a glance, you have to search for. There's simply no way those utterly redundant comments increase readability. (Yes, the real comments in the real code were just as redundant.)

LOC is more valid as a metric than most care to admit.

Re: Avoid Else, Return Early (2013)

#215

Post by Traubenfuchs »

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.

As someone who started out with C# and learned Java later, let me tell you: This is nonsense. You can get used to both easily, but only one of them saves space.

Re: Avoid Else, Return Early (2013)

#216

Post by tom_mellior »

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

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)

Re: Avoid Else, Return Early (2013)

#217

Post by 3pt14159 »

weinzierl wrote: post #200
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…

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

Oh common. This might be true for a very specific type of codebase, but it isn't true for programming in general. If I'm coding a library of standard statistical functions I'm exiting early. If I'm coding a Rails webapp I'm exiting early. If I'm coding a shell script, even one used on tens of thousands of servers, I'm exiting early.

The resource almost all programmers are managing is the resource of human time. Human time to code the project, human time to review the code, human time to alter the code after the fact, human time to port the code to different environments. If you're writing code to run AI at Google then fine, you're managing resources at a level where performance starts to hit limits that warrant a style change, but generally speaking you know that ahead of time and you choose tools to handle a project of the right scope, but generally speaking exiting early isn't impacting your code performance. Big O mistakes are.

Re: Avoid Else, Return Early (2013)

#218

Post by ivanhoe »

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.

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

Re: Avoid Else, Return Early (2013)

#219

Post by klmr »

jasonmaydie wrote: post #213
monocasa wrote: post #211

Earlier quoted context omitted.

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

it's not just about in app resources. This could also affect external resources.. like not cleaning up temporary files because a future maintainer returned early and left some critical data behind.

RAII can handle such resources, and good use of RAII does handle such resources. Languages without time-deterministic GC even tend to add extra language constructs to aid this, such as `using` in C# and Java (7?) with its new `try` block.

Re: Avoid Else, Return Early (2013)

#220

Post by drawkbox »

ajuc wrote: post #181
drawkbox wrote: post #75

Earlier quoted context omitted.

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.

Did you mean to use for with no counter instead? If so - I strongly disagree. I much prefer while(condition) {} to for (;condition;) {} For one thing you can't misplace ";" in a while loop. I agree that "do while" loops are unintuitive and rarely used, and thus the place to first check for bugs. Also they save very little so I just implement them as do(); while usually. But I know people who disagree about that, too,…

Basically what I am saying is while should be mostly off limits.

But yes if you end up in a loop you have some sort of counter/null checks or way out if you end up in a constant/recursive loop.

Never leave open the possibility of a lock due to being stuck in a loop.

Post reply on HN