Better Software - May 2008 - (Page 17)

Code Craft The Accidental Complexity of Logic by Kevlin Henney Logic lies at the heart of computation. Boolean algebra guides much of the course of a program’s flow. It is the stuff of programming. It is also, as Kernighan and Plauger noted in The Elements of Programming Style, the source of occasional confusion: “Boolean algebra is not used nearly as widely as ordinary arithmetic, so we must write logical expressions more carefully lest we confuse the reader.” They wrote this thirty years ago, but our ability to be confused has not lessened any in that time. Much code complexity, many programming thinkos, and no small number of program defects can be traced back to confusion over logical expressions and the expression of logic. In spite of our best aspirations and the relative simplicity of Boolean algebra, this is not the kind of thinking that comes instinctively to humans—even programmers. In many ways this state of affairs can be considered ironic. In formulating the calculus that bears his name, George Boole was pursuing an ambitious goal, as indicated in the title and opening of his 1853 work, An Investigation into the Laws of Thought: “The design of the following treatise is to investigate the fundamental laws of those operations of the mind by which reasoning is performed.” In practice, although we use Boolean logic correctly and effectively much of the time, the shortfall between the way we think and the needs of code presents sufficient opportunity for incorrect and unruly code to creep in. Dead Code Walking Consider the fragment in listing 1a, which is based on some code I saw a few years ago. if(collection.isEmpty()) { for(Item item : collection) { // about 30 lines of code } // about 20 lines of code } Listing 1a Given the chaos and low quality of the project as a whole, it is exceedingly unlikely that the illusory, lines-of-code productivity boost that the dead code gives was intentional. Omitting a not, or including a surplus one, or using an or where an and was meant, or vice versa, are common examples of errors that take code down the wrong path. Unit tests can be a great help in such situations: Staring at a piece of code for too long, you may possibly fool yourself into thinking that your inverted logic is correct, but a simple assertion is less easily duped. Of course, in the project in question there was no coherent form of testing—manual or otherwise—at any level, and because of the application’s high coupling, unit tests would have been pretty much impossible. Code review is a complementary way of uncovering such defects and would have been a suitable alternative. Code reviews do not have to be formal, and an informal pair walkthrough is often less time consuming and less threatening than walking through code in a meeting with many others. Because the body of the loop is unreachable, this becomes a rather longwinded way of writing the fragment in listing 1b. if(collection.isEmpty()) { // about 20 lines of code } Listing 1b if(distance > recommendedMaxDistance && userSelectedOverride && measuredValue >= minimumValue && measuredValue <= maximumValue && distance < recommendedMaxDistance) { result = false; } else if(!userSelectedOverride) { result = true; } else { result = false; } Listing 2a www.StickyMinds.com MAY 2008 BETTER SOFTWARE 17 ISTOCKPHOTO http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - May 2008

Better Software - May 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: It's A Bug! The Chivalrous Team Member Let's Talk Agile Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - May 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.