Better Software - May 2008 - (Page 18)

Code Craft Seeing the Forest for the Trees Simple thinkos are one source of error, but another comes from accidental complexity—making things more complex than necessary so that it becomes difficult to see what is going on. Consider the fragment in listing 2a, which is based on code I ran across (well, tripped over) many years ago. The code didn’t start out this way. It probably made sense originally—and even after a change or two—but eventually an addition led to a contradiction, which means the code reduces to the snippet in listing 2b. if(!userSelectedOverride) { result = true; } else { result = false; } Listing 2b or readable, extract and name a method that represents the whole condition rather than disassembling the logic into an if else tree. Boolean-to-Boolean Converters One particularly common and noisy kind of construct is what a conference attendee I once met referred to as the “Boolean-to-Boolean converter,” a name that nicely sums up the redundancy of such constructs. These are often characterized by extensive use of true and false literals and control flow structures. They all can be reduced to much simpler expressions. Here is a typical example of an identity converter: if(found) return true; else return false; Which is nothing more than: return found; And here is an elaborate negation: if(enabled) enabled = false; else enabled = true; Or, more concisely, to the code in listing 2c. result = !userSelectedOverride; Listing 2c Which is sometimes written slightly more compactly as: enabled = enabled ? false : true; This still reduces to something simpler and more direct: enabled = !enabled; Signal to Noise Ratio But unclear logic is not just about defects and dead code. Code can be functionally correct but developmentally poor. Clumsy logic also introduces accidental complexity, making the process of reading code more labored than it should be. The code in listing 3a includes a redundant check. if(!file.exists() || (file.exists() && !file.hasWritePermission())) return false; Listing 3a Listing 4a is a slightly more nested example. if(isOldest) { if(timeLastAccessed < cutOffTime) { return true; } else { return false; } } else { return false; } Listing 4a In this particular case, another programmer suggested the “simplification” shown in listing 3b, but it is not exactly an improvement. if(!file.exists()) return false; else if(!file.hasWritePermission())) return false; Listing 3b Its jagged formation still reduces to something briefer and more direct, as shown in listing 4b. return isOldest && timeLastAccessed < cutOffTime; Listing 4b Instead, for such a simple case, group conditions that have a common result, as shown in listing 3c. if(!file.exists() || !file.hasWritePermission())) return false; Listing 3c Should the condition become longer than is either reasonable 18 BETTER SOFTWARE MAY 2008 Sometimes a truth is established on one line, only to be restated using literals in repetitive form across subsequent lines as shown in listing 5a. Listing 5b demonstrates that both the decision structure and the use of the Boolean literals are unnecessary. www.StickyMinds.com 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.