Journal of my investigation into the development of a new programming language
Conditionals: ELSE IF
To me, one clue that ELSE IF is problematic is its many, many names (ELIF, ELSIF, ELSEIF). In my own programming projects, I've found that when I don't have a good name for something, it means I don't really have the concept right. Of course, various languages have
settled on their own terms for this, but that most of them are abbreviations (and low-leverage abbreviations - saving very few characters relative to the abbreviation length), and that they all seem to emerge with different
abbreviations, strikes me as a warning sign.
Another clue is the frequency with which ELSE IF is used in a far more constrained way than is allowed by the syntax. It is a sledgehammer of flexibility, permitting entirely unrelated conditions to be tested. But it is routinely used to swat the flies of CASE, comparing the same expression with alternate values, particularly in Perl
, which don't have native CASE support.
This reduces the readability of the code. Since the structure permits a universe of conditional complexity, the reader needs to keep more possibilities in mind when parsing ELSE IF than when parsing CASE.
Finally, like IF itself, ELSE IF poses indentation problems because it conflates answer and question. The ELSE part says, "contrary to the preceding test," and the IF part says both, "what about this next test?" and "if it's true, do this:".
The indentation issue has been resolved, in that standard convention is to indent it at the same level of the initial IF. But you could make a case for half-indents or extra indents - the ELSE IF isn't exactly the same thing, nor of quite the same weight, as the IF itself.