Code smell

from Wikipedia, the free encyclopedia

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

  1. ^ 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).