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

541–550 of 601 posts

Re: Avoid Else, Return Early (2013)

#541

Post by fouc »

jochung wrote: post #245
djsumdog wrote: post #143

Earlier quoted context omitted.

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…

The variable name can just be fooBar, and bazBar, and organized/namespaced such that you could have Thing.fooBar and Thing.bazBar (assuming you want those exposed to the rest of the application).

Readable variable names doesn't mean wordy names. I would avoid using more than 2 words in a variable name.

Re: Avoid Else, Return Early (2013)

#542

Post by Noumenon72 »

Kluny wrote: post #493
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 go more composition instead of inheritance. What does that mean?

Basically instead of Subtype extends Type inheritance, you just give your Type class a SubtypeHolder field. Makes it easier to add different behavior as things' types become less similar than you expected.

Re: Avoid Else, Return Early (2013)

#543

Post by Dylan16807 »

jcelerier wrote: post #302
fyi1183 wrote: post #117

Earlier quoted context omitted.

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.

> Fewer LOC means more code on the screen, which means you can more easily grasp the functionality of some piece of code, uh ? for me the less code on each line and the easier it is to read

When it comes to bracket placement, we're talking about empty lines. They don't affect the amount of code on a line.

Re: Avoid Else, Return Early (2013)

#544

Post by krallja »

eggpy wrote: post #517
dv_dt wrote: post #482

Earlier quoted context omitted.

FYI that quote is from Antoine de Saint-Exupry, author (and pilot) famous for "The Little Prince".

Do you know what the context of that quote is? I have used it as a sort of mantra specifically when programming, but I'm guessing it probably was intended for writing.

https://en.wikiquote.org/wiki/Antoine_de_Saint_Exup%C3%A9ry has the preceding paragraphs. It’s about the design of airplanes.

Re: Avoid Else, Return Early (2013)

#545

Post by Apatheticdino »

RobertRoberts wrote: post #291
psyc wrote: post #197

Earlier quoted context omitted.

For whatever it's worth, I insisted on single return for a long time when I was an intermediate programmer. 30 years in, I strongly prefer return early (as well as continue early in loops) and I cannot go back. The immensely reduced indentation is marvelous. Having that 'happy path' consolidated is more readable.

I find it interesting how most of the comments about return early are based on experience. I had the same thing happen about 10 years in. I just got sick of the extra coding and long indented blocks. And just switched over one day. Why is this not taught from day one?

I'd like to believe that this is a result of the concept of functions being first taught in the context of mathematics. Since there's no concept of flow control in mathematical functions, their entire purpose boils down to "Given parameters, do processing, return value".

Re: Avoid Else, Return Early (2013)

#546

Post by true_religion »

lisper wrote: post #387
true_religion wrote: post #373

Earlier quoted context omitted.

Python specific IDEs will smartly indent code upon copy and paste.

Sure, but if you somehow manage to screw up the indentation then no IDE can possibly restore it for you because the information needed to do it is lost. And there are a LOT of ways that indentation can get screwed up. If your code ever leaves the Python ecosystem (e.g. gets published on the web) then all bets are off because the entire digital world outside of the Python-sphere is built on the assumption that whitesp…

I don't know about that. I've never screwed up identaton so much that I couldn't correct it simply by selecting everything I just pasted and hitting tab a couple times in my IDE (PyCharm).

Similarly, copying code from StackOverflow, Github and random blogs have all worked without any issues.

So it can't be as easy as you imply.

Re: Avoid Else, Return Early (2013)

#547

Post by true_religion »

jonny_eh wrote: post #394
true_religion wrote: post #373

Earlier quoted context omitted.

Python specific IDEs will smartly indent code upon copy and paste.

How does an IDE know if a given line belongs in an if block or not?

It'll indent up to the most relevant valid block as possible, given your cursor at the moment. If you click within an if block, it'll indent into that if-block.

The indentation strategy also looks to produce syntactically valid code, so long as what you are pasting lacked indentation errors.

Re: Avoid Else, Return Early (2013)

#548

Post by true_religion »

pleasecalllater wrote: post #428
true_religion wrote: post #373

Earlier quoted context omitted.

Python specific IDEs will smartly indent code upon copy and paste.

Nope. Just try insert code formatter with 8 spaces into code formatted with 4, or 2. IDE will make something that compiles, it doesn't mean that it works properly.

Just tried that---typing like mad in a wordpad, with 12 spaces of indentation, then copying into PyCharm and it worked.

Mixed spaces and tabs as a next go, and it worked too---converting the pasted tabs into spaces of my style.

Smart-tabbing is pretty smart.

Granted, I knew that so long as the indents were proper (i.e it compiles), that pasting at that point would give valid code but... I can't see how using braces would have been different. Just because it compiles, doesn't mean it works. I've pasted javascript incorrectly multiple time to produce valid, but incorrect for my needs code.

Re: Avoid Else, Return Early (2013)

#549

Post by ovao »

RobertRoberts wrote: post #308
olavk wrote: post #58

Earlier quoted context omitted.

I am arguing this is worse, since it expresses the logic in a more convoluted way.

> I am arguing this is worse, since it expresses the logic in a more convoluted way. Ok, I really wonder if in this special case the logic just looks _odd_ because of bracing styles. (bear with me) This is very easy to understand, where as the parent example, not as much. fun max(a, b) { if a > b { return a } return b }

Regardless of bracing style, I still interpret `return a` as a special case with respect to control flow due to the indentation. `return b`, on the other hand, is on the "happy path" — if this wasn't simply a max function, I'd assume from the indentation that it'd return `b` most of the time.

A max function is one of those rare moments where a ternary statement just seems right, but it's an admittedly simple example.

Re: Avoid Else, Return Early (2013)

#550

Post by lisper »

true_religion wrote: post #546
lisper wrote: post #387

Earlier quoted context omitted.

Sure, but if you somehow manage to screw up the indentation then no IDE can possibly restore it for you because the information needed to do it is lost. And there are a LOT of ways that indentation can get screwed up. If your code ever leaves the Python ecosystem (e.g. gets published on the web) then all bets are off because the entire digital world outside of the Python-sphere is built on the assumption that whitesp…

I don't know about that. I've never screwed up identaton so much that I couldn't correct it simply by selecting everything I just pasted and hitting tab a couple times in my IDE (PyCharm). Similarly, copying code from StackOverflow, Github and random blogs have all worked without any issues. So it can't be as easy as you imply.

What can I say? It happened to me a lot before I started using the pass trick.
Post reply on HN