I am not talking about literal bad smell from your computer! I mean is there something “off” about it. Not a bug, but poor design or architecture weakness that will make maintenance a bear?
Defn: Code smell is any symptom in your source code that may indicate a deeper problem in your system. Just like if you open your fridge door and the smell is bad that is a sign that some of your food is rotting.
Code smells are (usually) not bugs — they are not broken code and don’t stop the program from run correctly. They are weaknesses in design that may slow down maintenance. Or may up your risk of future bugs and system failures. Bad code smell is a sign that you have serious technical debt!
What to do? Start refactoring in small steps to eliminate obvious bad smells; checking that the code still functions correctly at each stage. This will often uncover other worse smells deeper in the design.
Think of it like updating an old house – you rip off some bad drywall only to uncover decrepit electrical wiring underneath.
For example, You might start refactoring out duplicate code only to discover that the database design is bad too.
Code smells indicate when to refactor, and what to do to fix it.
Where bad code smells come from
Some surprising results in an IEEE software study of 500,000 code commits in 200 open source software projects found that:
- The majority of bad smells start at project creation, not during maintenance.
- Although regular maintenance is responsible for most bad smells added after creation, poor refactoring can add them too.
- Not all bad smells come from newbies on the code. Long time developers who are overworked and stressed are more likely to make new bad smells in code.
What do to have better smelling maintenance? Increased code review when the project is stressed!
The code smell zoo
- Duplicate code in different places.
- Contrived complexity: using over-complicated design patterns where simpler design would get the job done well.
- Hard coding of constants
- Instead use named constants to both improve readability and to avoid programming errors in future maintenance. Put the constants in a CFinclude file so they are easy to find and change.
- Orphan variable or constant class: a class that typically has a collection of constants that should be owned by another member classes.
- Large class: it is too big to read or fix easily. A “God object”.
- Feature envy: it uses the methods of another class too much.
- Inappropriate intimacy: it depends on the internal coding of another class.
- Refused bequest: it overrides a method of a base class but does not honor the original contract.
- Lazy class/freeloader: it does too little!
- Cyclomatic complexity: too many branches or loops. Break it up into smaller functions or write it in a simpler way.
- Downcasting: a type cast which breaks the abstraction model → refactor/eliminate the abstraction.
- Too many f*cking parameters: a long list of parameters is hard to read, and makes calling and testing the function complicated. Refactor so that responsibility is assigned in a more clean-cut way.
- Long method: a method, function, or procedure that has grown too large.
- Identifiers too long: eg using naming conventions to provide disambiguation rather making that clear in the software architecture.
- Identifiers too short: the name of a variable should reflect its function. Except if it is obvious.
- Too much return data: a function or method that returns more data than is needed to call it from all places it is used.
Have your lead developer pick a “smell of the week” Then ask all developers to look for it during their regular work this week. They may fix the issue themselves or bring it back to you. As you go through the above smell list will gradually teach your team to be better developers.
PS What was the ‘worst’ smell in your ColdFusion code last year? Leave a comment bellow.