Do a Good Turn

I read a great blog post called Boy Scout Check-ins by Jeff Mouser several months ago. This article really stuck with me both because I have been involved in many Scouting programs but also as a programmer. The basic premise of the article is to make an effort to leave the code in better shape than when you found it. Change a variable name, rearrange code to make it more readable, remove dead code or irrelevant comments, etc.

During my brief hiatus from Advantage I worked with one of our development teams working on a desktop synchronization solution. As with any mature project there are millions of lines of code which have gone through many revisions. This gave me a new perspective on how much work goes into a commercial product and just how much code it takes to create a successful program.

As the size of the codebase for a program expands the need for concise coding becomes very important. Not only will this improve performance but it also allows for easier maintenance. By ensuring that the code we write is clear and concise it benefits the entire team.

Additionally if you uncover an issue while working on an unrelated task take the time to make the fix whenever possible. In some cases it would probably take less time to fix a simple problem than it would to enter a bug into a tracking system to be fixed later. Similarly removing code that has been commented out is an easy way to improve the readability of the code overall.

Another change that can improve readability is variable naming. This assumes that you have a standard variable naming convention that is followed by the entire team, something that I highly recommend. As you can imagine this can be a simple fix for function level variables but gets much more complicated as the scope of the variable grows.

As a final thought you can improve the code by ensuring standard formatting is used throughout the code that you are working on. Again this is generally a simple task to do in a relatively short time. However, Raymond Chen made a good point in his post – if your going to reformat source code, please don't do anything else at the same time.

Little fixes can go a long way in both good and bad ways. The bigger the project the more potential for a little change to have big ramifications. Therefore we need to be good Boy Scouts and make sure our "good turns" don't create problems for others. This is where a good source code control system becomes a vital tool for when our little change breaks more than it fixes.