

Eschew ELSE - bdfh42
http://dobbscodetalk.com/index.php?option=com_myblog&show=Eschew-ELSE.html&Itemid=29

======
erikwiffin
This is similar to Return ASAP.
[http://patrickallaert.blogspot.com/2008/10/readable-php-
code...](http://patrickallaert.blogspot.com/2008/10/readable-php-
code-1-return-asap.html)

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

------
cryptnoob
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'.

~~~
pmichaud
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().

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

~~~
gjm11
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.

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

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

~~~
wglb
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.

~~~
gjm11
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?

------
edw519
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]

~~~
kelnos
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.)

------
FlorinAndrei
He means eschew the hyper-daisychained ELSE from hell.

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

