Posted by s.crouch on 30 April 2012 - 4:37pm

I first heard about “code smells” during a session I was chairing at Dev8D 2012 on “what makes good code good?”: Ian Bayley, from Oxford Unviersity, suggested “no ‘code smells’”. I’d never heard of this term so I turned to my trusty friend Google to see what was what. Although I hadn’t heard the term before, it turns out that I knew what code smells are… source code that just looks “odd” or doesn’t feel quite right, which are signs that suggests to a developer that refactoring might be in order.

Not only were many of the smells familiar but the “deodorants” were too. For example, replacing arrays that are used as records with objects,

String[] row = new String[3]; row [0] = "Liverpool"; row [1] = "15";

can be replaced by,

Performance row = new Performance(); row.setName("Liverpool"); row.setWins("15");

Or, replacing nested conditionals with guard clauses e.g.:

double getPayAmount() { double result; if (_isDead) result = deadAmount(); else { if (_isSeparated) result = separatedAmount(); else { if (_isRetired) result = retiredAmount(); else result = normalPayAmount(); }; } return result; };

can be replaced by

double getPayAmount() { if (_isDead) return deadAmount(); if (_isSeparated) return separatedAmount(); if (_isRetired) return retiredAmount(); return normalPayAmount(); };

The term “code smell” is attributed to Kent Beck in Martin Fowler’s book Refactoring, Improving the Design of Existing Code (Addison-Wesley, 1999, ISBN 0-201-48567-2). There are lots of online resources that will teach you how to spot smelly code and help with the deodorising so that your code ends up as pure as an Alpine breeze. As a starting point you could try Martin Fowler’s own “catalog of code smells and refactorings“, which lists both symptoms and cures, judiciously highlighted with examples. A complementary resource is Mäntylä and Lassenius’s “bad code smells taxonomy”. This groups together bad smells into a useful, recognisable and amusingly named taxonomy. As a couple of examples they have,

• The Bloaters, including long methods, large classes, long parameter lists and data clumps (sets of data like 3 integers for RGB colours which could be encapsulated).
• The Dispensables, anything which can, and should, be removed including lazy classes that don’t do enough, duplicated code, dead code and speculative generality (code which “might possibly be useful someday, maybe” but which incurs maintenance overheads).
• Other classifications are the change preventers, the couplers and the object-orientation abusers.

Another useful resource is SourceMaking’s pages on refactoring which motivates refactoring before describing many code smells and their refactorings.

Static code analysis tools such as CheckStyle or Pylint can also automatically detect (but not fix, that’s your job) code smells, and these might become a useful part of an nightly test system for your software, or part of a continuous integration server.

I hope this answers your question and the resources above will help you to write more fragrant code in future!