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

181–190 of 601 posts

Re: Avoid Else, Return Early (2013)

#181

Post by ajuc »

drawkbox wrote: post #75
tzahola wrote: post #72

Earlier quoted context omitted.

>Same way while/do/while is usually fades away, and if needed exit conditions. I couldn't interpret this sentence.

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, and shout at me for avoiding them:) It seems what's unintuitive for me isn't so for others.

Re: Avoid Else, Return Early (2013)

#182

Post by jakobegger »

vanderZwan wrote: post #134
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.

There is a ton of code that only exists because of issues elsewhere in the code . This is the opposite of brilliant code: these are the dirty patchworks, the hacks glueing the whole thing together. Yet often these hacks are necessary, at least until some bug is fixed elsewhere. Clear, self-documenting code is great but it can't capture that holistic insight into what the whole program is doing. It can't capture conte…

Also, any non-trivial software project is going to end up needing workarounds for bugs in other software. And you really need to document those. Because otherwise someone is going to remove that second refresh() statement, not knowing that this works around a bug in OS version xyz.

Re: Avoid Else, Return Early (2013)

#183

Post by psyc »

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've also been coding 30 years. I have to use same line at work, and I use next line in my (very large) side projects. Honestly, I don't know what the difference is.

Re: Avoid Else, Return Early (2013)

#184

Post by wereHamster »

> Error handling is noise.

Use a language which has syntax to automatically handle the error handling noise for you (dare I so do notation in Haskell). Go is egregious in that regard, the constant repetition of `if err != nil {…}`.

Re: Avoid Else, Return Early (2013)

#186

Post by ajuc »

scott_s wrote: post #173
ajuc wrote: post #144

Earlier quoted context omitted.

Comments that answer "what" are redundant. Choose your identifiers better. Write good commit messages and comments that answer "why" are redundant too. Commit messages by their nature refer to the exact code that they refered to when they were written. Comments answering "why" after a few years are misleading anyway, because code changed around them. Commenting public api etc is obvious, and most people do it.

When you read through a part of your system that you've either never seen before or have forgotten how it works, do you also read all commit messages for all of that code? I'm asking because that's the only way I can imagine one can learn about the edge cases and surprising consequences in non-trivial systems if you have a rule about not using comments to explain them.

No, I do a git blame, and see all the relevant commit messages.

If there's not 1 line of code from that commit remaining why is it relevant?

If something looks weird still - I go back to the commit that created this part of code and git blame that. I don't remember a case where I had to do 2 steps like that.

BTW we have a rule of putting JIRA ticket numbers in commits, that makes it even easier to find out. You can see the whole discussion that resulted in the code you try to understand, test cases that you don't want to break with your new changes, etc.

Re: Avoid Else, Return Early (2013)

#187

Post by TomMarius »

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

Tabs, everyone can configure them however they want. :-)

Re: Avoid Else, Return Early (2013)

#188

Post by ztjio »

Haven't looked into it for a while, but, it used to undermine the JIT compiler to use multiple return statements in a single method in Java.

That said, I entirely disagree with the premise. I find it vastly easier to reason about a function/method that does not return early. To me, this is on par with writing switch statements that don't cover all the possible values: a sin.

Re: Avoid Else, Return Early (2013)

#189

Post by gambiting »

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

As a C++ programmer I can assure you, I know plenty of individuals with very strong opinions on tabs vs spaces debate.

Re: Avoid Else, Return Early (2013)

#190

Post by dhimes »

scott_s wrote: post #146
vanderZwan wrote: post #134

Earlier quoted context omitted.

There is a ton of code that only exists because of issues elsewhere in the code . This is the opposite of brilliant code: these are the dirty patchworks, the hacks glueing the whole thing together. Yet often these hacks are necessary, at least until some bug is fixed elsewhere. Clear, self-documenting code is great but it can't capture that holistic insight into what the whole program is doing. It can't capture conte…

Completely agreed. Put another way: the sentiment that code documents itself is only possible in purely logical systems with no edge cases or surprising consequences. As an example, our code base has a comment which refers to our internal issue tracker which itself refers to this HN comment: https://news.ycombinator.com/item?id=9048947

It's also only possible if the code is thought of as a text and is proofread/edited rigorously for reading. My process is 1) write the code quickly- add comments 2) revise for clarity and efficiency (usually modularity), remove comments as confidence allows. This is where I might get the variable and method names correct for self-documenting code. Usually it takes several passes. But most often, "good enough is good enough" and I leave comments in. Just in case.
Post reply on HN