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

241–250 of 601 posts

Re: Avoid Else, Return Early (2013)

#241

Post by bunderbunder »

youngtaff wrote: post #175
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'm with you on Allman style braces, prefer it and find them much easier to read. As everyone else seems to use K&R I've just had a adapt over time :-(

What's interesting to me is, anecdotally, the people I know who are the biggest K&R haters are people who started with K&R, then had to switch to Allman for a significant length of time, and then had to switch back to K&R.

Re: Avoid Else, Return Early (2013)

#242

Post by weinzierl »

3pt14159 wrote: post #217
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…

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…

Cleaning up resources after use is not a question of performance, it is a question of correctness.

Re: Avoid Else, Return Early (2013)

#243

Post by seanmcdirmid »

louthy wrote: post #192
seanmcdirmid wrote: post #180

Earlier quoted context omitted.

You aren’t really reducing complexity with the monadic approach, just replacing explicit control flow for implicit control flow masked as data flow. Debugging can become harder in the latter case.

Which is written once, rather than 1000s of times. That's a reduction in cognitive load and the same 'missing else' bugs I mentioned. I agree it's not always easier to debug - but mostly (I find) writing code as pure expressions rather than a sequence of statements reduces the need for debugging massively. So, I don't think it's quite as black and white as you paint.

No, you usually have to debug just as much, you just don't have any nice tools to do it with. I agree the monadic approach looks cleaner, but just be ready to undo it for any kind of hairy logic that requires debugging.

Re: Avoid Else, Return Early (2013)

#244

Post by z3t4 »

SideburnsOfDoom wrote: post #38
reacweb wrote: post #31

Before I heard about the single exit point rule, I have coded during many years using multiple exit points. I am complying with the rule for many years and I am quite happy with it. The code is slightly more nested, very slightly longer to type. But OTOH, the style checker can spot mistakes in my code and there is less thinking about how I will structure my code to make it smarter. IMHO, the gain is small but not sma…

> single exit point rule, What makes it a "rule" or as sometimes said, a "law"? It's just a style, and it has pros and cons, cases where it helps, and cases where it hinders.

It's interesting when style becomes rules, the years goes by and no one challenge the "best practice", languages and frameworks might change, but the rules stay, for no good reason. So yeh, why only one return !?

Re: Avoid Else, Return Early (2013)

#245

Post by jochung »

djsumdog wrote: post #143
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.

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.

I have the exact opposite experience. If you find yourself annotating your variables and methods with extra adjectives and nouns, your code isn't simple enough. Those explanations go in code comments.

Often it means you can refactor it so that there is only one of any "thing" so there is no need to clarify which version or role this "fooBarThing" is serving to disambiguate it from the other "bazBarThing".

Functional composition and well structured data is the key to this. It's basically halfway to point-free style.

Re: Avoid Else, Return Early (2013)

#246

Post by zerostar07 »

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.

for a vi user, visually selecting a block to its matching end for cutting/pasting is the equivalent of coding photoshop

Re: Avoid Else, Return Early (2013)

#247

Post by yorwba »

vortico wrote: post #191
tzahola wrote: post #87

Earlier quoted context omitted.

You're turning RAII upside down... Learn to use proper RAII and you won't need this defer hack.

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

Re: Avoid Else, Return Early (2013)

#248

Post by jehlakj »

foobarchu wrote: post #102
arghwhat wrote: post #79

Earlier quoted context omitted.

I would argue that it is by no means more convoluted. It is quite clear and concise. All of the following are equally readable: if (x > y) { return x; } else { return y; } if (x > y) { return x; } return y; return (x > y) ? x : y; The logic would be convoluted if you are going through extra hoops in order to write your logic like this, making the flow of the application unclear. For some things, an else branch ends u…

I think it's only clear and concise looking because of the achilles heel of this entire thread: terse examples. As soon as you need to do more than a single line of work, the else'd version becomes far more readable (due to superior indentation and clearer guarantees of what happens when). If it's a single line of return in both branches, then a ternary expression is usually going to be ideal instead.

If you’ve ever had to deal with various errors or to filter out something and return the appropriate output, it is much more concise. Read past the if’s and you have the main logic of that function.

But that max function should have an else statement since it's part of the logic. Less code doesn't always make it more concise. If there's a more complicated logic, then it'd actually be harder to understand at a glance.

Re: Avoid Else, Return Early (2013)

#249

Post by tzahola »

vortico wrote: post #191
tzahola wrote: post #87

Earlier quoted context omitted.

You're turning RAII upside down... Learn to use proper RAII and you won't need this defer hack.

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 ¯\_(ツ)_/¯

Re: Avoid Else, Return Early (2013)

#250

Post by 3pt14159 »

weinzierl wrote: post #242
3pt14159 wrote: post #217

Earlier quoted context omitted.

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…

Cleaning up resources after use is not a question of performance, it is a question of correctness.

Choosing an environment that requires you to clean up resources instead of handling it for you is mostly a question of performance.
Post reply on HN