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

111–120 of 601 posts

Re: Avoid Else, Return Early (2013)

#111

Post by optimuspaul »

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.

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.

Re: Avoid Else, Return Early (2013)

#112

Post by drawkbox »

sk5t wrote: post #100
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…

Oh sweet summer child. This list reflects but one possible course of programmer evolution. Some languages--and I'm thinking particularly of scala--encourage one-liners. Comments are rarely extra weight if there's anything worth explaining; access modifiers are not of the essence here. Collection types are no replacement for OO patterns that have a reason to exist in the first place. There's a good argument to be made…

> encourage one-liners

Less merge friendly as well. Also you should only do one thing per line when it comes down to it to increase simplicity. I like compact code but not adding complexity for no reason so others on the team can be confused.

> Comments are rarely extra weight if there's anything worth explaining

Good cases are non obvious flows and especially algorithms/notes or any section that will be public or generate docs from it. But mostly comments are weight not because they aren't good, but because they aren't updated and become out of date weight.

> Collection types are no replacement for OO patterns that have a reason to exist in the first place.

They definitely have a place but prototyping even they are better. They are the base of json/xml data formats and most languages. Everything on top of that should have a reason for complexity including OO as long as it improves understanding and simplicity.

The "simple but not too simple" rule is what a programmer/engineer should live by.

> good argument to be made that early exits, other than perhaps constraint checking, make control flow harder to reason about

I'll fight to the death for better flow with early exits it is much easier flow with less indentation. There are times where you do need to go about it differently but most do not.

Re: Avoid Else, Return Early (2013)

#113

Post by [deleted] »

wildmusings wrote: post #35
dep_b wrote: post #20

Earlier quoted context omitted.

`goto` wouldn't be used in a return early philosophy.

Goto is heavily used to return early, by jumping to the cleanup section at the bottom of the function. Otherwise, you have to repeat the cleanup code at each exit point, or use the dreaded pyramid of doom where each failure point introduces another indent level, which is what the author here is trying to avoid in the first place.

[deleted]

Re: Avoid Else, Return Early (2013)

#115

Post by Mithaldu »

optimuspaul wrote: post #108
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 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.

Comments are not documentation.

Documentation explains HOW to use a thing. Good comments explain WHY a thing is strange. Bad comments explain WHAT a thing does and must be made redundant by extracting and naming the thing.

Re: Avoid Else, Return Early (2013)

#116

Post by 3pt14159 »

Quarrelsome wrote: post #85
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 move on from heavy OO to dicts/lists. OO is better if the objects tell a story in a way that ProviderStrategyDataFetchers fail to do so and are effectively just wrappers for data structures. If you go pure data structure without story you just end having to add comments to explain purpose. The comments are the classes.

I agree with both you and the OP. OO where necessary, lists and dicts where things are simple. You can always take a list of strings and turn it into a list of objects. But going the other way is harder because you have to refactor anything that depends on them.

Re: Avoid Else, Return Early (2013)

#117

Post by fyi1183 »

jrimbault wrote: post #91
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…

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

Oh but it is, independent of the language. Fewer LOC means more code on the screen, which means you can more easily grasp the functionality of some piece of code, which makes it easier to maintain.

Re: Avoid Else, Return Early (2013)

#118

Post by mden »

jrimbault wrote: post #91
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…

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

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

Re: Avoid Else, Return Early (2013)

#119

Post by fouc »

optimuspaul wrote: post #108
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 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.

Re: Avoid Else, Return Early (2013)

#120

Post by scraft »

I think the real transcendence is when you try out many different programming paradigms (all of which have loads of good reasons to use) and overtime find out the shortcomings of each. Then just pick the right tool for each use case.

The general information here I think is good and I roughly follow. I have also done almost the opposite and removed as much code outside of the hotpath as possible from the top of the function for performance reasons (guided on profiling). Also there can be times where you jump to a function to see what it does and can't actually see as all of the edge cases come first rather than the bread and butter.

Often you need to be careful when thinking a new paradigm is fixing a problem, like handling the err variable being passed in, and question why there is an err parameter at all. Where does it come from. What are you actually meant to do when it happens? Does every case always just log it, or throw it? Is the logic being performed at the right level? Etc. Sure the answer maybe yes everything is correct but there will be lots of times that the complexity just shouldn't be there.

Horses for courses.

Post reply on HN