Get it All

Logic is binary. Statements can either be evaluated as true, or as false. There are no “maybe’s” in logic. As such, one could be forgiven if they thought that a binary system’s best expression would be a perfectly-bisected world: a world in which concepts evaluate as true as often as they do false. One would expect code created in this world would work as effectively on both sides of the boolean divide.

But developers figure out sooner or later that nothing could be further from the truth. Nothing about the duality of logic creates a truly binary system. In fact, the word “false” encompasses a world of bad options much larger than the word “true.” And counter to our natural sense of the world, that multiplicity makes “false” a weaker rather than stronger concept.

Decision making code epitomizes this idea. This most basic logical decision maker, the “if/else” evaluation, contains within it the central paradox of logic. In this evaluation, we ask the system to evaluate “if” a statement is true. In that case, we execute another block of code. If the statement evaluates false, we execute a block of code after the “else” keyword.

if( statement ) {
// code block
} else {
// another code block

This is among the most basic of code concepts. And as they begin writing scripts that do simple things, most students end up using this structure to create code that is more-or-less balanced, if versus else. Values for which there are only two desired values get used to make assumptions about how the code should continue on.

if( $person is "female" ) {
// things that concern women
} else {
// things that concern men

But wait. Is sexual identification really binary? No, of course it is not. And therefore, while the code contained in the “if” block can be entirely “true” and the code block it reveals confidently executed with that knowledge – a person could identify as “female” – any one of a number of other possibilities would all evaluate to “false” – they may not be female, but they don’t identify as male, either – making code contained within this second block highly suspect.

Ok, setting aside the hot-button social issues, let’s consider a real-world example of actual code for why this duality is not a reliable way to execute code. Consider an application you might build to respond to web requests for data. You’re providing a listing of calendar events to an entire city’s-worth of bloggers through a web API. When they want to know which acts are playing locally, they’re going to request that list from you, giving you their location and list of acts they want to know about.

But wait. Are they sending that list? They’re supposed to, but you can’t be certain that the information they send to you is correct, or even that it exists at all. In this context consider this code:

if( username identified in system ) {
// Do things for an identified user
} else {
echo "Oops! Looks like you aren't logged in!"

If the user passes a username over and if that username is found in the system, we can execute code that would be acceptable for registered users. But can we make a similar assumption for every other alternative to an identified user? There could have been an error transferring data. The user might not have included the username. They might have passed values in the wrong order, so an email address gets passed where the username should be. They could have passed an integer value when you needed a string of characters; they may have passed a CSV-formatted value where you expected JSON.

Returning a user the generic, non-specific message above when an entirely other problem exists is confusing. And inasmuch as your job as a developer isn’t to code someone else’s software, it also isn’t your job to make their job harder by sending them on a wild goose chase.

Be the If, never the Else

“If” blocks represents certainty. “Else” is simply the catch-all condition for everything you don’t know and can’t control. That’s not to say we don’t need Else: while If evaluates true for a single condition, the possibilities for what a user might pass an application are infinite from the perspective of the code.

But what happens in your Else ought to be brief and informational. Respond to user requests with detailed errors. Commit error details to an error log. Redirect a user to an earlier part of the code, and then be done. Else is an offramp to safety, not a continuation of a Twist-a-Plot book.