fun with short circuit operators

Got a practical lesson today in why knowing stuff like how “short circuit” operators work is important. Read on, if you dare.

A simple example, and then the PerlMonks article that showed me where I went wrong.

We’ve got a new corporate directory application that allows our users to update several attributes in their profile, which is stored on an LDAP directory server.

In reporting out changes made by the users I have been careful to validate the values in each attribute we’re checking before including them in the statistics. One particular field on the profile form allows users to select their location from a drop-down list. As usual the top item on the list is “– Select Location –“, and this is what the user sees when they first open the form. Most applications of this kind would include a hook to exclude that value from any commit, since no user would consciously choose it. Right,

Anyway, due to this oversight I have to filter out this value before counting the field as filled out by the user. I also need to filter out any null or blank values entered there.

That’s right, I left schema checking off too long.

My solution looks something like this:

if(($location =~ /w+/g)&&($location !~ /Select/gi)) {
    $countloc++;
}

Only problem was that those “Select” values kept showing up in my statistics!

On a hunch I reversed the order of the terms:

if(($location !~ /Select/gi)&&($location =~ /w+/g)) {
    $countloc++;
}

and voila! They were gone!

So what’s up with that? Turns out there’s a well-known mechanism at work here surrounding “C-style Logical (Short Circuit) Operators”, which are something right out of K & R’s classic The C Programming Language (Prentice Hall, 1988). These operators include the symbols “&&” and “||”, representing “and” and “or”, respectively. The important point to understand is that, according to Wall in Programming Perl (2000, O’Reilly), “They are known as short-circuit operators because they skip (short-circuit) the evaluation of their right argument if they decide that the left argument has already supplied enough information to decide the overall value”. Basically this means that if the left condition is satisfied, then perl won’t bother to evaluate the right hand one.

In other words the reason my first expression failed to do the job is that the match on “=~ /w+/g” was deemed sufficient to “solve” the problem, and as a result my “!~ /Select/gi” didn’t need to be addressed. In essence, “w+” matched all alpha numeric values found, including those spelled S-e-l-e-c-t. Reversing the order of the expressions changed the game entirely, because “/Select/gi” only matched a small subset of the data presented, and so perl evaluated both sides.

Perl Idioms Explained – && and || “Short Circuit” operators on the PerlMonks site explains this all much better than I ever could, and is a must-read for anyone working with these operators in perl.

This entry was posted in System Administration, Systems Analysis on by .

About phil

My name is Phil Lembo. In my day job I’m an enterprise IT architect for a leading distribution and services company. The rest of my time I try to maintain a semi-normal family life in the suburbs of Raleigh, NC. E-mail me at philipATlembobrothersDOTcom. The opinions expressed here are entirely my own and not those of my employers, past, present or future (except where I quote others, who will need to accept responsibility for their own rants).