Code smell is a term used in software development to describe surface-level observations in design that indicate deeper systemic issues leading to negative outcomes. This term was coined by Martin Fowler and Kent Beck in the 1999 book Refactoring: Improving the Design of Existing Code (1).
Code smell has also been referred to as Design Smells, such as in Robert C. Martin’s 2002 Agile Software Development, Principles, Patterns, and Practices. In this book, the following characteristics are outlined as consequences of “Design Smell:”
Rigidity – Single changes require other changes.
Fragility – Changes cause breaks in unrelated parts of the system
Immobility – System components can’t easily be decoupled and used in other systems
Viscosity – The system makes it easier to adopt poor coding practices than correct ones.
Needless Complexity – Unwarranted infrastructure for simple functionality
Needless Repetition – Designs containing repeating code that could be abstracted and unified.
Opacity – The functionality of a system or feature is unclear
These characteristic design smells are described by Martin Fowler as things that are quick to spot. That is, code smells are often subjective observations “sniffed” out by experienced developers as opposed to results of testing or quantitative analysis.
Coding practices like code reviews, pair programming, and refactoring can all help to spot potential code smells. These principles of code and design smells are not concrete guidance. Just because there is repetition does not mean that software is poorly designed. One should always ask “what is this supposed to do” when considering the presence of code smell. When answering this question, don’t be afraid to dive down a rabbit hole investigating a new class of problems!
Fowler, Martin, and Kent Beck. Refactoring: Improving the Design of Existing Code. 1st ed., Addison-Wesley, Addison Wesley Longman, Inc., 1999.
Martin, Robert C. Agile Software Development, Principles, Patterns, and Practices. 1st ed., Pearson, 2002.