// JSON-LD for Wordpress Home, Articles and Author Pages. Written by Pete Wailes and Richard Baxter. // See: http://builtvisible.com/implementing-json-ld-wordpress/

A Decision Is No Place for Side-Effects

As developers become more comfortable with their favorite syntax(es) they tend to favor terseness in coding.  This isn’t something limited to those writing programs.  The fact is, as people become more comfortable with a situation they look for ways to shorten interactions and bypass redundancies.

For example, as we become more comfortable with cooking, we may begin to approximate measurements.  We’ve measured a teaspoon of salt a hundred times.  We know that if we go slightly over or under it won’t ruin the recipe, so we just cup our hand and pour until it looks right.  At the gas pump I never press the “Pay by credit card” button.  Instead I insert my card and the machine recognizes what I am doing.  No need for the extra step. 

When communicating we shorten common phrases.  We may create compound words, contractions, or acronyms.  The goal is to reduce the overhead and increase entropy.  That is, we want each word we utter, or command we type, to do more for us.  When working with software we often refer to “power users” who know all the shortcuts to quickly access the program’s features.

Those who are new to the situation will need the more verbose and redundant approach.  Just because power users know how to bypass an application’s menus, a novice will still need the menus to help him or her learn the software. 

In a similar light, experienced developers need to consider their junior brethren as programs are being created.  At a basic level the issue is that the software may be maintained by others and those developers may not be as experienced as the original authors. 

One high-risk programmatic shortening concerns side-effects in decisions. 

Many languages support unary and assignment operators within the context of a decision.  They also support Boolean operations and may short-circuit portions of the Boolean expression once its outcome is guaranteed.

For example, in C# if I have two int variables called linecount and charcount where each is assigned 0 (zero), the expression if (linecount > 0 && charcount > 0) will only evaluate the first test.  Since the Boolean expression requires that both tests be true, once the first is determined to be false there is no need to check the second.

This is an example of terseness applied by the environment to save computational effort.   Where it can become an issue is when side-effects are placed in the test.

Given our earlier variables, consider the test below.  Regardless of the test result we know that linecount will be incremented by 1.  For an experienced programmer a terse approach like this makes sense.  However, a less seasoned developer can be tripped up when editing this code.

if (linecount++ > 0) {
     charcount += countChars(linecount);
}

Imagine that the code needs to be changed so that we only call countChars() if a Boolean variable, called doCountChars, is true.  The programmer changes the code as follows:

if (doCountChars && linecount++ > 0) {
     charcount += countChars(linecount);
}

Now if the code is told not to count characters it also won’t count lines.  It is unlikely that this behavior is intended.  A bug has probably been introduced.

I believe that the goal of programming should be to produce an application that meets the users’ needs (encompassing good performance and few bugs) and be easily maintained.  In fact, since programs spend over 99% of their useful lives in maintenance (as opposed to being built) there is no advantage to simplifying life for the original author, only for the maintainer.

Had the original code been written as:

linecount++;
if (linecount > 1) {
     charcount += countChars(linecount);
}

Then the updated code:

linecount++;
if (doCountChars && linecount > 1) {
     charcount += countChars(linecount);
}

Would not have risked introducing any subtle flaw since we aren’t counting on a side effect within the (potentially) short-circuiting test.

In the case of decisions, I recommend that side-effects not be permitted.  The potential for downstream bugs isn’t worth the few characters being avoided during initial development.

One Response to “A Decision Is No Place for Side-Effects”

  1. evanspa Says:

    I completely agree 100% I’m of the belief that we have to continually be at battle with one’s self, and this is yet another area of life in which we need to battle our nature. In this case of wanting to “increase entropy w/less overhead” because our comfort level has gotten high :)

Leave a Reply

You must be logged in to post a comment.