The term "code smell" has been around for a while to indicate a particular quality of software code that suggests a problem or bad practice.
I'm convinced that this term does not belong anywhere in the discourse of a mature development team.
On the one hand, "code smell" successfully and clearly conveys a meaning: "There's something wrong here." But the negatives far outweigh this one positive.
Here are six reasons to drop this term now.
1. It's Demeaning
The main reason to do away with this term is that it's demeaning. When another person comes along and points out something in your work as a "code smell," how is this any different than saying, "Your code stinks." All you've done is dress up your insult, but it's still an insult.
2. It's Condescending and Lazy
Good teams are made of teachers who will give each other the benefit of the doubt and offer suggestions instead of pointing out flaws. Frankly, any criticism that is not actually a suggestion is merely a power trip or self indulgence. Why bother to comment if you're not going to tell me how you think I should fix it. And if you do tell me how I could fix it, then what's the point of starting with a criticism? Skip the criticism and get straight to the suggestion.
And if you think there might be something wrong but aren't sure what it is exactly, then don't make a statement, ask a question. If you don't have an answer, then all you have is a question.
Employ your brain and take responsibility for your comments. Not doing so is lazy. It's easy to say, "That's bad code." But it might actually take some energy to clarify why it's bad code and offer a suggestion.
3. It's Non-specific
Aside from being demeaning and condescending, "code smell" is like firing a gun in the air. It can get people's attention, but, by itself, it doesn't tell you what's wrong. And like I said before, if you know what's wrong, why not just say that?
Every good developer knows that the devil is in the details. I spend most of my days responding to questions with more questions. In life, but especially in software, if you jump to conclusions about what someone means, you're probably wrong. Always ask more questions to make sure you understand the problem. "Code smell" always demands an explanation. If you use this term, you should be prepared to defend why you used it and explain yourself and your reasoning clearly. Just like firing off a gun at an outdoor bake sale, you've got our attention, now you better be able to justify your action.
4. It's Smug
Look, there are many types of developers, but I think we can all agree that our profession has its share of know-it-alls. We've all known one, or two...or ten. They are cock sure that their way is the right way because, hey, they read it on some celebrity dev's twitter feed.
Over the last 20 years of my software career I've watched mass hysteria unfold many times. Everyone declares that this new technology, this new SDLC method, this new design strategy is the ONLY acceptable approach. I've had managers tell me that EVERYTHING must be wrapped in try-catch. I've heard people suggest that XML would replace databases. I've heard people say that AJAX based services would replace post backs. I've heard people say that Agile is the only acceptable methodology, and that code should NEVER have private methods.
These practices and ideas start out based in truth and have some usefulness within a certain context, but as they get elevated to religious doctrine and promoted by passionate acolytes, the truth and the context are lost. Then certain devotees use them as tools with which to bludgeon other developers, often in a quest to boost their own egos or, just as likely, because they lack a deep understanding of their subject.
In time, all of these extreme positions have, or will, fade back into their proper place. They are tools--helpful and useful when used properly, in the right context.
5. It's Disgusting
Obviously, the term "code smell" is intended to evoke a kind of visceral reaction, the kind we might have when walking into a remote national park bathroom. You open the door and the stench wafts over you like a gross blanket.
While two co-workers are free to discuss personal or even disgusting topics, such things are not appropriate for professional discourse. Out of politeness, you would generally avoid a vivid description in the middle of a meeting of how disgusting the bathroom smells today.
While you are, of course, free to say it, it's disrespectful to your colleagues in the same way other types of speech are also frowned upon in professional or polite company.
When something is labeled a code smells it's often an overreaction and fails to acknowledge the subtle and creative nature of software development.
While I support coding standards, developers are unique individuals and often come up with something new, useful and better. To walk around with a chip on your shoulder, waiting to label something as a code smell, is to close your mind.
If you have ever stopped to think deeply about a subject, you'll soon find there are many different sides to the story. There's nothing in this world, that is black & white. There is an exception to every rule.
Well, gravity, you say. If I jump off a building I'll die.
Right, so there are even exceptions to that. You've heard stories of people jumping off of buildings without dying, or even falling out of airplanes and surviving.
Well, Steve, but they fell on a very steep snowy slope.
Nope. Not all of them.
But, that's rare. Those are very special circumstances and you'd have to land just the right way.
OK. Sure, if you get specific enough, then maybe you can start to say that something is always true or always false, but that's the point!!! And thank you for proving it. "Code smell" is a generalization to the point of not being helpful. It's only when you get into the weeds, the details, that you can start to make useful claims.
People are particularly prone to black and white thinking, but real world problems are messy. Even the smallest piece of code becomes complex when you start asking questions about it. Often, you don't care because a certain approach is sufficient, but if you think in black & white terms, then you'll never notice the subtle issues. And every project has subtle issues.
Finally, for you die-hards, I'm sure you'll say you want to keep the term around because it is so very useful and to the point. It's a great way to convey that you think there's a problem.
Useful? Possibly, but it does suffer from all of the things above. And in my book, the fact that it's rude, demeaning and condescending is enough reason to damn it to oblivion.
Of course, in the spirit of this article, I wouldn't bludgeon someone for using the term, but I would discourage its use and make sure that it's not a common or formal part of your team activities.
Besides, there are plenty of alternatives. Instead of saying, "That's a code smell," try these:
- "Hi Rob, here's an approach that might work better."
- "Becky, could you explain why you chose to do it that way?"
- "John, would you mind if I show you another way to do that?"
- "Well, Amy, that works, but there's a new best practice we've decided to use instead for this project."
Like the recursive GNU acronym, "code smell" is itself a "code smell." If you use the term on your team, I hope you'll reconsider. If not for others, then for yourself, because it's probably hurting you and your team more than you think.