Hacker News Reader

Comment by edw519 | Hacker News Reader

"...and it often simplifies the code to have multiple returns."

Today. And what happens after 10 other programmers modify your slick little multi-return function? Nobody will ever be able to modify it again because the entries and exits are lost among the garbage. This is the ongoing debate I've had for years with "clever programmers". They're missing one critical point: the guidelines of structured programming are not meant to make your life easier; they're meant to keep the code alive longer by making life easier for the poor schmuck who has maintain it (usually me).

Another Sign You're a Crappy Programmer:

You make your own rules in direct violation of effective established principles because you think you know better.

View on HN

Early returns make code more readable. I'd rather detect an error and bail then have a slew of nested ifs.

It isn't always about being clever.

"I'd rather detect an error and bail then have a slew of nested ifs."

And here's what inevitably happens when you do that:

14 mods are applied and your early exit(s) get lost in the muck.

Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months.

Then I come along, find the errors, fix the data base, advise the user of the effects of the damage, and rewrite the whole program with single entry/single exit processing so that this never happens again. And then post to a board like this only to re-engage in the same old debate.

Aside from poorly named variables, violation of "single entry/single exit" is the biggest lifespan reducing problem of code bases I've ever seen.

This is the future speaking. Please don't do that.

I see where you are coming from, but I'm just not buying it. First, 15 different programmers are rarely touching the same piece of code over any short or medium span of time. Second, even over the long term, if you have programmers who don't read the code they are making changes to before they change it, you should fire them.

You can make the same argument that a bunch of nested ifs is going to end up with a lazy programmer who doesn't know what conditions need to be met, so he puts it in the wrong place, and now all of your careful code is broken. Coding style is ultimately pretty personal, and this is no different.

"15 different programmers are rarely touching the same piece of code over any short or medium span of time"

I see it all the time. But then again, maybe I'm like the blind man with the elephant; I only know what I've encountered.

Wouldn't it be great if analysis was conducted properly, design specs were tight, functional specs were accurate, projects were managed properly, programmers were trained, resources were adequate, and the people paying the bills had a clue as to what they needed? I've never seen it. That may be why code gets modified so many times. I've even seen "quick & dirty" temporary programs still in production for 15 years. This is the world we have to deal with. That's why we adhere to structured programming principles: to save ourselves a whole lot of trouble down the road.

That's why "return" (and "throw" and "assert") is syntax-highlighted in most editors. ;-)

Honestly, I've never had a case where I visually missed an early exit. Most of the time, such exits are guard statements, designed to bail out with an exception if some precondition isn't met. Most of the rest, they're "found it, don't need to do any more processing" and apparent from the logic. I'll usually mark the latter with a quick comment anyway, just to be sure I don't miss them.

And early returns let you apply additional invariants to your code. You've checked your preconditions and bailed if necessary; you don't need to worry that this array might be null. You've handled the 1-item base case; you don't need to worry about your recursive function blowing up. I find that broken invariants cause many, many more bugs than missing an exit and not executing code.

"I've never had a case where I visually missed an early exit."

Too bad the same's not true for those I have followed. And when it does happen, it makes the worst kind of mess - the kind you don't discover until 6 months later.

Guidelines and rules are not meant for the best of us; we don't need them as much. They're meant for the mediocre masses who are everywhere and wouldn't know any better.

Agreed.

Cue the blame-the-programmer-for-not-being-smart-enough comments.

Guys. The goal isn't to provide the "perfect" code that somehow those poor average schmucks just can't understand. The goal is to provide the dumbest, easiest-to-follow narrative of how the computer is going to solve the problem for the user so that the next guy is able to understand it.

The goal is to conceptualize the problem in such simple terms that even a machine could solve it. Then do so.

"Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months."

I can certainly see how this is true in a large organization which hires lots of mediocre programmers. However, if you're in a company where the other programmers are top notch, this sort of thing is not a problem.

In fact, if I ever see nested ifs and such in a function where I work, it gets changed to the least number of lines of code possible. I can do this because there is only 1 other programmer here, and I know he's not going to screw it up.

I don't know your situation, obviously, but my initial reaction is... "Holy crap man... run!"

"if you're in a company where the other programmers are top notch"

I've never seen such a thing (and I've seen alot).

Reason #127 for starting your own.

reason #1 to get a new job. You might have seen a "lot", but you've seen a lot of the wrong thing.

lol - I've often wondered about that. I once remarked to a partner, "Why do we see so much crap?" He responded, "Cause the people who know what they're doing have no reason to call us."

Questions I have would be:

Why is the function being modified 14 times? It sounds like the original abstraction was poorly conceived. I would hope that at some point before edit #15, someone would think to break the function down into smaller pieces.

If your programmers were a) competent or b) wrote tests this wouldnt happen. If they're not competent and don't write tests they should be fired.

Ah. Didn't read this when I replied earlier: http://news.ycombinator.com/item?id=83107

You make sense. However, I would just try to find more interesting work than cleaning up after others and then trying to get them to change in a certain way :)

The number one sign you're a crappy programmer:

1. You foist idiocy upon others and refuse to listen when they point it out as such, because someone told you that the idiocy was "effective established principles".

Your "effective established principles" seem to be neither effective, nor established, nor principled.

"neither effective, nor established, nor principled"

http://en.wikipedia.org/wiki/Structured_programming

Isaac Newton "stood upon the shoulders of giants." Interesting to see that you know better.

-----------------------

"...someone told you..."

Actually, I learned what I'm sharing in this thread (and much, much more) from MANY excellent mentors. I hope you find some, too.

----------------------

"The number one sign you're a crappy programmer"

I have hundreds of (well paying) clients that would disagree with you.

----------------------

I "foist" standards only upon those who work for me. You won't ever have to worry about that.

I'll give you the vote because very often hard-set rules in programming are not good.

That's what the other rule is for, to not make functions span too many lines ;-)

Don't worry so much about how you or others will modify it, and how it may look when it's 10 times hairier. That's what refactoring is for.

Reply on news.ycombinator.com