Code Smell

Any fool can write code that a computer can understand, good programmers write code that every human can understand. – Martin Fowler

Code smells are not bugs or errors. Instead, these are absolute violations of the fundamentals of developing software that decrease the quality of code.

Having code smells does not certainly mean that the software won’t work, it would still give an output, but it may slow down processing, increase the risk of failure and errors while making the program vulnerable to bugs in the future. Smelly code contributes to poor code quality and hence increases the technical debt.

There are 3 types of Code Smell

Application Level Smells

1. Duplicate Code – Similar code in more than one location.
2. Shotgun Surgery – One change requires altering many different classes.
3. Contrived Complexity – Using complex design patterns where a simpler uncomplicated design could be used.

Class Level Smells

1. Large Class – Class trying to do too much and has too many instance variables.
2. Freeloader –  Class doing too little
3. Feature Envy – Class with a method that seems more interested in another class than the one it is in.
4. Divergent Code – A class that suffers many kinds of changes to bring a change in a system.
5. Data Clump –  Bunches of data that clump together in lots of places.
6. Inappropriate Intimacy – A class that has dependencies on implementation details of other classes.
7. Middle Man – Class with lots of methods delegated to other classes.
8. Downcasting – Typecast that breaks the abstraction model.
9. Parallel Inheritance Hierarchy – Every time you make a subclass for a single class, you are needed to make a subclass.
10. Refused Bequest – Subclass not using methods and data of superclass.
11. Cyclomatic Complexity – Class with too many branches and loops.

Method Level Smells

1. Long Method – Long procedures that are hard to understand.
2. Speculative Generality – Methods whose only users are test cases.
3. Message Chains – Method calling a different method which calls a different method which calls a different method… and on and on.
4. Too Many Parameters – A very long list of parameters.
5. Oddball Solutions – When multiple methods are used to solve the same problem in one program creating inconsistency.
6. God Line – An excessively long line of code.
7. Excessive Returner – A method that returns more data than what its caller needs.
8. Identifier Size – The identifier is excessively short or long.

Code Smell Example

Comments

Are Comments necessary?

1. Why?
2. What?
3. Comments are for people not for machines.
4. Think about refactoring the code so that comments are not needed.

Long Method

Try avoiding longer methods. Short methods are easier to read & understand for a developer who looks at the code.

1. Ideal lines of code -20.
2. Methods with 5 lines of code, indicate that you are breaking up the code too much, making it harder to understand,

Too Many Parameters

Avoid too many parameters in the method signature.

1. The ideal number of parameters (as per check style static code analyzer) is -7
2. Keeping it less than 5 makes it easy to read and understand.

Type Embedded in Name

Avoid embedding types to the variable names.

Some Bad Example

1. List<String> listofStudents;
2. String student;
3. Int amount

Inconsistent Names

Many developers have trouble with naming the methods with efficient names.

Examples

1. Use lowercase for packages.
2. Use camel case of variables and method names.
3. Avoid using ‘_’

Dead Code

Unused code? Or commented code? Delete it before pushing to the repository.

Solution Sprawl

If you have too many classes to perform a solution, you might have a solution sprawl.

Time to refactor the code.