Hand checking code seems to be a dying art. At least for students that is. Throw some code into the IDE and hit F5 to compile and run and then see what happens. “Ready, Fire, Aim”
At the risk of sounding like the old guy reminiscing about the good old days that were not really so good I can’t help but remind people what it was like in the days when you could expect to get to the computer once a day. Each shot at the computer meant one compile/run/test cycle. One really had to be careful about what you sent to the computer and that meant you went over your code carefully, by hand, before letting the computer get at it.
Back in the day that meant you looked for syntax errors as well as logic errors. I’m not so sure that letting the computer do most of the syntax checking is all that bad an idea anymore. On the other hand, really bad things can happen if the logic is wrong. I still like the idea of looking at the code closely, pretending to be the computer to make sure that the algorithm works the way it is supposed to work.
Call me old fashioned if you’d like but to me spending some time to double check the code by hand to the point of having a high level of confidence in the results seems like a good idea. When the program has its first clean compile and runs for the first time it shouldn’t be a surprise that it works correctly. All too often it seems as though programmers, well mostly beginners, put together some rough set of code with the hopes that it will achieve close to the correct result. Once they see how close they get they assume they can gradually fix things. While iterative development is in many ways a good idea it would be a lot better to go from success to greater success than from near success to closer to success.
This is the twenty-first of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this “proverb” are of course very welcome here.