The more I write about various code, the more I notice a particular trend: Everyone has an opinion.
No matter what code or pattern I discuss, there are always some who like it and some who don’t. Be it singletons, multitons, dependency injection, output parameters, prototypical inheritance – it doesn’t matter.
It’s been a universal phenomenon that when code snippets are included, someone somewhere will bring up the term “code smell.”
What is “code smell?”
Code smell is a euphemism for an indication that something is wrong in the design of an application on a deeper level. A physical analog would be an odor coming from your fridge, indicating that perhaps something has rotted somewhere inside.
Code smells are usually not bugs—they are not technically incorrect and do not currently prevent the program from functioning. 1
On a high level, this could mean you’re using an anti-pattern somewhere in your code that, while it won’t hurt you today, will likely cause architectural issues in the future. For example, using a singleton to wrap functionality in a quick proof-of-concept prototype will work, but will cause issues when your try to add unit testing later to flesh out the project.
Code smell is, functionally, a yellow flag in your application that should be addressed quickly, but it’s probably not top priority.
What do developers mean when they mention code smell?
With a few notable exceptions, developers often invoke “code smell” because they don’t like an approach or pattern, but can’t articulate why.
Highly experienced and knowledgeable developers have a “feel” for good design. Having reached a state of “Unconscious Competence,” where they routinely practice good design without thinking about it too much, they find that they can look at a design or the code and immediately get a “feel” for its quality, without getting bogged down in extensive “logically detailed arguments”. 2
There is rarely, if ever, justification to structure a program based on a developer’s “gut feeling.” Yes, an experienced developer can often look at a design or code and understand its quality – but if he can’t articulate why it’s good or bad, I would argue they are not as knowledgable as they pretend.
A good developer can explain why she used one design pattern over another. When asked, “why did you index this database column” or “why didn’t you index this database column,” she should be able to explain the reasoning behind the decision – or be willing/able to adjust her approach given this inquisitive feedback.
An “experienced” developer citing “code smell” when looking at your code (who can’t articulate why your code smells) is a developer who merely doesn’t understand your approach and is putting on airs while reviewing it. 3
For many developers, “your code smells” is not a euphemism for poor approach or design. It’s a cover for “I don’t understand what you’re doing here or why and I don’t want to be seen as less experienced than you.”
My code smells
My code often smells. Sometimes it’s because I was lazy in my initial approach and used the wrong design pattern that comes back to bit me later. Sometimes it’s because I’m learning a new set of design structures and implement them poorly.
Sometimes it’s because I make a conscious decision to use an overused design pattern in a certain way. Still other times it’s because I’m using an approach with which other developers are unfamiliar, so they write the approach off as “smell” and move on.
I’m OK with all of the above because I’m more than willing to explain why I’ve done what I’ve done, even if my explanation is “I was lazy, that was wrong, I’ll fix it.”
The question isn’t whether or not I’m capable of explaining smell in my code – it’s are you capable of explaining why you think it smells in the first place?