Code smell
In programming, code smell , or smell for short (German '[bad] smell') or German bad-smelling code, is a construct that suggests a revision of the program source code. According to reports, comes the metaphor Smell of Kent Beck and gained widespread use by the book Refactoring by Martin Fowler . The term was intended to describe more tangible criteria for refactoring than would be provided by a vague reference to program aesthetics.
Code Smell is not about program errors , but about functioning program code that is badly structured. The biggest problem is that the code is difficult for the programmer to understand, so that new errors often creep in when making corrections and enhancements. Code smell can also point to a deeper problem that is hidden in the bad structure and that is only recognized by a revision.
Common smells
The following smells described by Martin Fowler and Kent Beck relate to object-oriented programming , but have obvious equivalents among other programming paradigms.
- Code duplication
- The same code occurs in different places.
- Long method
- A method (function, procedure) is too long.
- Great class
- A class is too big, has too many instance variables, and duplicated code. See also God Object .
- Long parameter list
- Instead of passing an object to a method, object attributes are extracted and passed to the method as a long parameter list .
- Divergent changes
- For a change, a class must be adapted in several places.
- Operating out shotgun bullets
- This smell is even more serious than divergent changes: For a change, further changes must be made to many classes.
- Envy (English Feature Envy)
- A method is more interested in the properties - especially the data - of another class than in those of its own class.
- Chunks of data
- A group of objects often appears together: as fields in some classes and as parameters of many methods.
- Inclination to elementary types (primitive obsession)
- Elementary types are used, although classes and objects are more meaningful for simple tasks.
- Case statements in object-oriented code
- Switch-case statements are used, although polymorphism largely eliminates the need for them and solves the related problem of duplicated code.
- Parallel inheritance hierarchies
- For each subclass in one hierarchy there is always a subclass in another hierarchy.
- Lazy class
- A class does too little to justify its existence.
- Speculative generality
- All sorts of special cases have been provided that are not needed at all; Such general code needs maintenance effort without it being of any use.
- Temporary fields
- An object uses a variable only in certain circumstances - the code is difficult to understand and debug because the field does not appear to be used.
- Message chains
- The Law of Demeter is violated.
- Middle Man (intermediary)
- A class delegates all method calls to another class.
- Inappropriate intimacy
- Two classes are too closely interwoven.
- Alternative classes with different interfaces
- Two classes do the same thing, but use different interfaces for this.
- Incomplete library class
- A class of a program library needs extensions in order to be able to be used in an area suitable for it.
- Data class
- Classes with fields and access methods without functionality.
- Refused Bequest
- Subclasses don't even need the methods and data that they inherit from the superclasses (see also Liskov's substitution principle )
- Comments
- Comments generally make it easier to understand. Often, however, comments seem to be necessary exactly where the code is bad. Comments can therefore be an indication of bad code.
More smells and programming anti-patterns
In addition to the smells mentioned by Fowler, there are also a number of code smells that are often mentioned under programming anti-patterns :
- Insignificant name (Uncommunicative name)
- Name that says nothing about the properties or use of the named. Meaningful names are essential to understanding program code.
- Redundant code
- A piece of code that is no longer used.
- Indecent Exposure
- Internal details of a class are unnecessarily part of its interface to the outside world.
- Contrived complexity
- Forced use of design patterns where simpler design would suffice.
- Too long names
- In particular, the use of architecture or design components in the names of classes or methods.
- Too short names
- The use of "x", "i" or abbreviations. The name of a variable should describe its function.
- About callback
- A callback that tries to do anything.
- Complex branches
- Branches that test a lot of conditions that have nothing to do with the functionality of the code block.
- Deep nesting
- Nested if / else / for / do / while statements. They make the code illegible.
Architecture smells
In addition to the smells addressed by Beck and Fowler in the source code of applications, smells also occur in the architecture of software systems. These were described by Stefan Roock and Martin Lippert.
The architecture smells include:
- Cyclical usage relationships between packages, layers and subsystems
- Size and division of the packages or subsystems
See also
literature
- Martin Fowler: Refactoring. How to improve the design of existing software . Addison-Wesley, Munich 2000, ISBN 3-8273-1630-8 , pp. 67–82 (English: Refactoring. Improving The Design Of Existing Code . Translated by Bernd Kahlbrandt).
Web links
- Refactoring An overview that explains some important smells in section 2.3 under the title "Bad Smells".
Individual evidence
- ^ Martin Fowler: Refactoring. How to improve the design of existing software . Addison-Wesley, Munich 2000, ISBN 3-8273-1630-8 , pp. 67–82 (English: Refactoring. Improving The Design Of Existing Code . Translated by Bernd Kahlbrandt).