Defining "bug" part 2
As our former intern and I continued our discussion about what constitutes a bug, our conversation meandered over to code reviews. Code reviews refers to the peer review of code that happens before we are allowed to check in. On a simple level, we check for coding style and guidelines to ensure that if we want camel Casing, then you are indeed using camel Casing and not Camel Casing.
It was at this level I asked if a typo in a comment was a bug or not. For instance, if you had
//now imcerment the counter
Should I file a bug and request you spell "increment" correctly before you are allowed to check in? After a lot of grammar debate, we decided that in this case, if this were the only issue found with the code, then we would not hold up checking the change in. We figured that any reasonable person would be able to see that the word "increment" was the intention of the author and we would not want to delay the change while this typo was fixed.
But consider this one:
//the counter does not get incremented
count++;
Can you spot the typo in this case?
The word "not" should have been "now," as in "The counter now gets incremented."
In this case, we decided that this could lead to confusion when reading the code later. If the comments says the counter should not be incremented, but the code clearly increments the counter, then debugging around this code at some point in the future would be made more difficult. I would not know whether the comment in the code was the expected behavior or if the code as written was expected. While this is a relatively simple example, our thought that if the comments are not clear, then the comments need to be changed before checking in. And since there is no time like the present, we would enforce a change to the comments before checking in.
It may seem odd that we would hold up a change because of a comment, but in this case we felt justified in calling this a bug and insisting on it getting fixed.
Questions, comments, concerns and concerns always welcome,
John