Beautiful Code [346]
Figure 32-5. Number of DiffMerge's if statements at successive indentation depths per release
Correlation is not causation, as they say, and of course there could have been other contributing factors. The design of the enhancements, the test cases, the other coding constructs—even the size of the source code file—any or all of these could have contributed to the higher rate of errors. But given what we know about deeply nested conditionals and comprehensibility, it's hard not to take this glaring correlation at face value.
The 2006 overhaul of DiffMerge was driven by a mandate to overcome indentation. The overhaul replaced deeply nested conditionals with switch statements whose case options were values defined in the new diffGrid decision table. The table, whose layout was designed to be human-readable, itemized all the conditions we were currently handing and gave us placeholders for conditions we might eventually want to handle. Thus, we not only replaced troublesome code, we gave ourselves headroom for future enhancements.
Code in Motion > Conclusion
32.7. Conclusion
To a programmer working on code in motion, beauty is code that can be modified with a minimum of fuss. You read the code, determine what it does, and change it. Your success depends as much on how well you understood the code to start with as it does on your ability to code. It also depends on how well your code is understood by the next programmers to tackle it; if you're never called in to help them out, you've done well.
Were we to trim the narrative from this chapter, all we'd really have left to say is that the success of code in motion depends on how comprehensible it is to the programmers who read it. But this is not news to anyone.
What is news is that programmers read code in diffs, patches, merges, compiler errors, and debuggers—not just in syntax-colored text editors—and that they frequently, if unconsciously, infer logic from the visual appearance of code as well as from the code itself. In other words, there's more to comprehending code than meets the eye.
In this chapter, we've examined the effect of using "The Seven Pillars of Pretty Code" as guidelines to make code more comprehensible in more contexts. We've had success with the Seven Pillars. We've used them to write code that can move with the flow of change, and we think that's beautiful.
Code in Motion > Acknowledgments
32.8. Acknowledgments
Christopher Seiwald, James Strickland, Jeff Anton, Mark Mears, Caedmon Irias, Leigh Brasington, and Michael Bishop contributed to DiffMerge. Perforce Software holds the copyright to the DiffMerge source code.
Code in Motion > Further Reading
32.9. Further Reading
Kim, S., Adaptive Bug Prediction by Analyzing Project History, Ph.D. Dissertation, Department of Computer Science, University of California Santa Cruz, 2006.
McConnell, S., Code Complete, Microsoft Press, 1993.
McMullin, J., Varnhagen, C. K., Heng, P., and Apedoe, X., "Effects of Surrounding Information and Line Length on Text Comprehension from the Web," Canadian Journal of Learning and Technology, Vol. 28, No. 1, Winter/hiver, 2002.
O'Brien, M. P., Software Comprehension - A Review and Direction, Department of Computer Science and Information Systems, University of Limerick, Ireland, 2003.
Pan, K., Using Evolution Patterns to Find Duplicated Bugs, Ph.D. Dissertation, Department of Computer Science, University of California Santa Cruz, 2006.
Reichle, E.D., Rayner, K., and Pollatsek, A., The E-Z Reader Model of Eye Movement Control in Reading: Comparisons to Other Models, Behavioral and Brain Sciences, Vol. 26, No. 4, 2003.
Seiwald, C., "The Seven Pillars of Pretty Code," Perforce Software, 2005, http://www.perforce.com/perforce/papers/prettycode.html.
Tufte, Edward R., The Cognitive Style of PowerPoint, Graphics Press LLC, 2004.
Whitehead, J., and Kim, S., Predicting Bugs in Code Changes, Google Tech Talks, 2006.
Writing Programs for "The Book" > The Nonroyal Road
33. Writing Programs for