The power of names actually…
I’ve come across this code the other day:
So, what is wrong with that code? Nothing in particular, it compiles and runs fine, so it’s perfect. Well, it is actually, until other people start using it and making assumptions about what resultOfComparison really means. (seems a little bit awkward to me to name a boolean variable resultOf… It’s either true or false. A result -for me- is something that you cannot guess with a chance of 1:2). Basically resultOfComparison was meant to keep track of whether a repository is up to date or not.
Since we as people are different we re thinking differently; We also like to be lazy a bit (not to browse through the code but make assumptions). It just happened in this case too. As different people had worked on the same feature, they imagined differently what resultOfComparison should have been in different situations. The following two pieces of code have been created:
The first guy thought resultOfComparison must be false when the repository is up to date. The other one was sure that it has to be the other way around.
Yeah, not a big deal, one might say. Just correct one of the classes according to business logic and the glitch is solved. True. And easy to see indeed. But what if you have a system of 3000+ source files? Then you end up with a dysfunctional system, have to cancel a demo and spend a whole day in debugging.
The whole thing could have been avoided only by giving the variable a meaningful name, like repositoryUpToDate; so everyone could have seen how the particular thing have to behave runtime. The worst thing about this annoying bug was that all unit tests were in place. And all of them were green. They were based on the two different assumptions too…
I’ve refactored that name a bit, it became isInventoryUpToDate, so with a quick “find references” I was able to track all the issues down. Then all the broken conditions were trivial to fix. Kind of annoying bug; a whole day wasted. 😦