Thursday, August 28, 2014

Code Smell

A code smell is an indication of the presence of an underlying problem within a software code. It could indicate a problem with s/w design, or architecture. Code smells are symptomatic of a system bottleneck that prevents / limits the development of s/w or increases the likelihood of a s/w failure.

 

- Code Smell

- Design Smell

- Architecture Smell

 

Common Code Smells (Wikipedia)

  1. Duplicated code: identical or very similar code exists in more than one location.
  2. Long method: a method, function, or procedure that has grown too large.
  3. Large class: a class that has grown too large. See God object.
  4. Too many parameters: a long list of parameters is hard to read, and makes calling and testing the function complicated. It may indicate that the purpose of the function is ill-conceived and that the code should be refactored so responsibility is assigned in a more clean-cut way.
  5. Feature envy: a class that uses methods of another class excessively.
  6. Inappropriate intimacy: a class that has dependencies on implementation details of another class.
  7. Refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class. See Liskov substitution principle.
  8. Lazy class / Freeloader: a class that does too little.
  9. Contrived complexity: forced usage of overly complicated design patterns where simpler design would suffice.
  10. Excessively long identifiers: in particular, the use of naming conventions to provide disambiguation that should be implicit in the software architecture.
  11. Excessively short identifiers: the name of a variable should reflect its function unless the function is obvious.
  12. Excessive use of literals: these should be coded as named constants, to improve readability and to avoid programming errors. Additionally, literals can and should be externalized into resource files/scripts where possible, to facilitate localization of software if it is intended to be deployed in different regions.
  13. Ubercallback: a callback that is trying to do everything
  14. Cyclomatic complexity: too many branches or loops; this may indicate a function needs to be broken up into smaller functions, or that it has potential for simplification