Thoughts on the Craft of Programming: Abstraction, Refactoring, and How Changes Introduce Bugs (Page 1 of 6 )
This article is about the craft of programming, which comprises both scientific and artistic elements. By "scientific," I mean that programming concerns logical propositions that are objectively true or false, and by "artistic," I'm referring to the many ways to formulate these propositions and the need to make subjective judgments about which are good and which are bad. When discussing software development, we tend to bandy about the grand concepts of modularity and abstraction without a real understanding of how these concepts are reflected in our everyday work. When it comes to improving and refactoring chunks of software code under development, I believe it's worth exploring the reasons -- the motivations -- behind the code improvements. I think there are some general principles that may guide programmers toward producing code of higher quality.
One of the problems, of course, is that in making code changes, we frequently introduce new errors into the code, even when we are being careful, even when the change is apparently simple and the existing code is well-structured. So to make my ideas concrete, I will examine a fragment of code known to contain an error, and I will explain the error and illustrate a simple change that will correct it. I will then make several improvements to the code to make it easier to read and maintain.
Finally, I will add a new feature. The piece of code used here is trivially simple, much too small to really show the advantages of modularity and refactoring, but I believe it is big enough to illustrate the basic principles. It's written in C and uses native types, because that's how the code that originated all this discussion was designed; and I have kept the K&R style because I feel it is, as Tony Hoare1 said about Algol-60, such an improvement on all its successors. For clarity, I have omitted the #include statements that would be required.