Software Journal

As a code reviewer, certain things tend to bother you more than other things.  Here is the list of 3 things that bother the @*(# out of me.

• Using code as the revision control system:  Developers tend to comment out code, not delete it.  Call it pride of authorship or something else, but it is difficult to delete that excellent, eloquent, functional piece of code that was relevant before your product/project manager decided to change the requirements completely (and completely out of blue, barely x hours after lauding your excellent work!).  The main justification that the developers tend to give is, “Well, what if we want to add that feature back?”  Well, Joe, no, we are never going to bring that feature back!  Never.  Never, ever.  Because we never change our mind.  But just in the slimmest possible lemon peel of a chance that we do bring that feature back, then we will use the RCS to go hunt for that piece of code, or better, you will redo it from scratch!  You wrote such good code the first time around, that I just shudder in awe of the future code that you will write when you have already written that once.  So, for now, stop using code as your RCS, be brave and delete the code.  If we have to give Developer Medals of Honor (DMoH), then, that should be awarded to the brave developers who have written something fabulous and deleted it from their code when requirements changed, thus relegating that phenomenal piece of code to the deathly hollows of the RCS, and done it without evincing pain.
• Using naming conventions that are beyond wrong: This one causes no visible problems, other than sometimes befuddled customers or higgledy-piggledy users who are confused that the browser bar is showing “AddInvoice.jsp” or something similar, when they were clearly trying to edit an existing invoice.  Horror of horrors!  The customers are just not adept at recreating the thought process of the developer Alice when she was creating the page the very first time, before the first invoice existed at all!  So, Alice conveniently called it the AddInvoice page, and since she is a good developer who follows the reuse principle, Alice decided to reuse the same page for editing an invoice.  Alice, imaginative as she is, did not consider the possibility that a glasses, jeans/t-shirt wearing user would actually notice the URL when using a part of the application.  Clearly, there is no shortage of horror movies in the software world.
• Using single liner if else blocks: This one is the easiest of the problems to fix.  Just make this a hall of shame qualifier in your team (or a compiler error in your IDE settings).

  No one should write if else logic that does not use curly braces to wrap the pieces of logic that go inside the if and the else blocks.  This really is just a code format issue, but the number of times that I have seen this cause sudden bugs to appear in the version X.0.1 when version X.0 seemed to run absolutely fine is far too many to let this go by.  Too many times, a developer will add a log statement to the first line of the else block, entirely changing the meaning of the block.  This one should be considered the one-liner joke equivalent of the software comedy genre.