Eschew ELSE | Hacker News Reader

Eschew ELSE

dobbscodetalk.com

10 pointsbdfh4216 comments

This is similar to Return ASAP. http://patrickallaert.blogspot.com/2008/10/readable-php-code...

Reading that prompted a major change in my coding style, and in my opinion, a major improvement in readability.

I've lately found myself doing more of this, rather than switch statements or if/else. It works when you find yourself in a function that does only that thing, but often, you're in much more complex function, and you're not ready to return a value. Should you split this code into it's own function, allowing this type of structure, or use the switch, or if/else? I don't add functions for reasons as weak as this, so in those cases, I still have to use 'else'.

I'll add functions at the drop of a hat. Even for one line of code: instead of commenting the line to explain that it Does Foobar, I'll just drop it into a function DoFoobar().

I know I'm probably being too conservative from my years doing embedded and assembly programming, but I disagree with this.

As you know, there is a cost to adding functions. They are not free from a code performance standpoint. Are they so close to being free that you don't need to worry? That depends on the processor and the application. I still do embedded and assembly programming, so I can't afford to drop this habit, because there, it does matter. So for web apps, I continue to use them liberally, but definitely not "at the drop of a hat".

With a Sufficiently Smart Compiler (tm), there is no cost to adding functions because the compiler can inline them. FWIW, on the simple example I just tried "gcc -O3" is a sufficiently smart compiler.

I'd like to hear more about this sort of thing. Are there any other good resources/discussions on adding functions?

You should read Martin Fowler's Refactoring, it's the bible on that sort of thing.

This is why I almost exclusively use COND in lisp. Each clause has the condition explicitly spelled out and I am much less likely to err.

Except that the last condition can be T, and that's exactly the same as "else" in a more conventional language.

Yes, in a way, but it happens much less often. If you leave off the final clause, then it is exactly equivalent of his rewritten example.

I don't think it is. The point of his rewrite is that at the end of each branch the function returns so that you don't have to remember so much to make sense of what it does.

Sure, a COND that's the only (or final) form in the function that contains it has the same property, but the key thing there is that it's at the end, not that it's a COND. COND really is the same thing as if ... else if ... else ...; using that rather than IF when you have more than two branches is a good thing, for sure, but I don't see how it's good for the reason you give.

Am I missing something?

ditto. I'm the same way in my lisp code. It's almost the only conditional I use. Well... maybe condp as well.

Show me any tool and I'll show you a horrible use of that tool. That doesn't make the tool horrible.

ELSE statements don't kill. Drunk programmers kill.

This reminds me of something I once ran into:

Junior Programmer:

  if (m==1){Month="January")}
  if (m==2){Month="February")}
  if (m==3){Month="March")}
  if (m==4){Month="April")}
  if (m==5){Month="May")}
  if (m==6){Month="June")}
  if (m==7){Month="July")}
  if (m==8){Month="August")}
  if (m==9){Month="September")}
  if (m==10){Month="October")}
  if (m==11){Month="November")}
  if (m==12){Month="December")}

Senior Programmer:

  switch(m)
  {
  case 1:
    Month = "January"
    break;
  case 2:
    Month = "February"
    break;
  case 3:
    Month = "March"
    break;
  case 4:
    Month = "April"
    break;
  case 5:
    Month = "May"
    break;
  case 6:
    Month = "June"
    break;
  case 7:
    Month = "July"
    break;
  case 8:
    Month = "August"
    break;
  case 9:
    Month = "September"
    break;
  case 10:
    Month = "October"
    break;
  case 11:
    Month = "November"
    break;
  case 12:
    Month = "December"
    break;
  default:
    Month = "unknown"
  }

Lazy Programmer:

  MonthNames == ["","January","February","March",...]
  Month       = MonthNames[m]

s/Lazy/Smart/

The code is much more compact and much easier to read. (Of course you'd do bounds checking on 'm' before the assignment, but that's not a huge burden.)

He means eschew the hyper-daisychained ELSE from hell.

I think it's time someone lifted mainstream programming languages from the world of control-structures that some guys in the sixties thought were enough. I cringe every time I see C/C++/Java/C#/etc. code that would benefit hugely from more expressive control-structures.

Reply on news.ycombinator.com