Nearly all programmers are passionate about one thing — their coding style. This is kind of ironic considering this is a populace of people who, with few exceptions, could pretty much care less about style in any other aspect of their life — clothing, home decor, personal hygiene…

When I fix a bug in someone else’s code, sometimes I cringe at their coding style or lack thereof. On occasion, I find myself in some code that I can genuinely admire the clarity and attention to detail. I like to think of fixing bugs, in your own code, or in someone else’s, as a kind of spot-welding. The goal is to put in a clinically minimal change to fix the problem.

Here are a few tips for creating a clean, but strong spot-weld.

a) Adapt to the existing code style — whether good or bad

Example:

1
2
3
4
5
6
7
8
9
10
11
12
13
    int foobar(int *arr[], int n) { 

        int i,count=0; 

        for (i=0; i<n; i++) { 

           if ( arr[i] == 0 ) { 

              ++count; 

           } 

           if(arr[i]<0)/*fix*/ 

                 { 

                 break; 

                 } 

        } 

        return count; 

     }

Different brace style, indentation, spacing around punctuation, and a nearly worthless comment, “fix”. The coder who put in this fix put his ego and love for his style ahead of consistency. One thing you will find about any programmer’s style: no matter what the brace style, no matter what the spacing preferences, in general, inconsistency is ugly.

b) Adapt to the existing naming conventions — whether good or bad

Granted, some people’s naming conventions are difficult, nay, impossible to recognize, but there are simple facets that can always be mimicked to improve consistency. Do they use mixed case? How do they use underscores? Do they use a naming prefix pattern? Do they use a naming suffix? What are some of the root words that represent the concepts being worked with?

Making your changes mesh with the existing conventions — whether good or bad — will make your changes fit in with the code around it and it shows a degree of professionalism. The code’s original author is less likely to doubt the quality of your change if it fits in.

c) Adapt to the existing structures and coding constructs

Example: You may use exception handling in all of your code. Programmer X may use return codes. When you do a fix in programmer X’s code, you should adapt to his constructs, even if you think they are archaic, because consistent, archaic techniques are better than inconsistent application of two very different techniques.

Another example: Don’t write a class to fix a bug in code that doesn’t use any classes, unless it is the only solution. Again, think of the concept of a spot-weld.

d) Beautify the code, but don’t check in the beautifications

If you just can not read a piece of code because of it’s style, go ahead and beautify it. But once you have a fix, revert back to the original style and merge your fix back in. This keeps the amount of change to a minimum which will help the next person who has to review the change history of that code.

e) Leave a note behind

When you fix a bug, leave your initials and the date with a short comment saying, “heh, I was here, I did this, and it was supposed to fix something.” That will save other people who see the code time when they are wondering who to blame (or who to give credit to). This is one area where I think it is ok to diverge from the existing code style. You should leave a note behind even if it is the only comment in the entire code base. You can think of it as good manners.