4 ms·

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.

by boucher 19y ago

edw519 19y ago
"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.
- boucher 19y ago
  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.
  - edw519 19y ago
    "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.
- Goladus 19y ago
  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.
- tyler 19y ago
  "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!"
  - edw519 19y ago
    "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.
    - cstejerean 19y ago
      reason #1 to get a new job. You might have seen a "lot", but you've seen a lot of the wrong thing.
      - edw519 19y ago
        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."
- nostrademons 19y ago
  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.
  - edw519 19y ago
    "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.
- cstejerean 19y ago
  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.
- DanielBMarkham 19y ago
  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.
  - apathy 19y ago
    The goal is to conceptualize the problem in such simple terms that even a machine could solve it. Then do so.
- akkartik 19y ago
  Ah. Didn't read this when I replied earlier: http://news.ycombinator.com/item?id=83107 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 :)

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.

by boucher 19y ago

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.

edw519 19y ago

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

boucher 19y ago
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.
- edw519 19y ago
  "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.
Goladus 19y ago
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.
tyler 19y ago
"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!"
- edw519 19y ago
  "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.
  - cstejerean 19y ago
    reason #1 to get a new job. You might have seen a "lot", but you've seen a lot of the wrong thing.
    - edw519 19y ago
      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."
nostrademons 19y ago
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.
- edw519 19y ago
  "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.
cstejerean 19y ago
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.
DanielBMarkham 19y ago
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.
- apathy 19y ago
  The goal is to conceptualize the problem in such simple terms that even a machine could solve it. Then do so.
akkartik 19y ago
Ah. Didn't read this when I replied earlier: http://news.ycombinator.com/item?id=83107 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 :)