Code smells usually provide hints that may point to deeper underlying issues in the code structure and architecture. According to Martin Fowler, they are often an indicator of a problem rather than the problem themselves.
Let’s look at some common ones:
Long methods, like their name, are too long.
- Difficult to grasp explicitly what a method does at a glance
- It has more than one level of nesting
- It exceeds more than one level of abstraction.
Sandi’s recommendation: Methods can be no longer than five lines of code.
Large classes are difficult to understand. In addition, it is harder to change or reuse behaviour. Adding test cases and making changes in the code is also challenging.
- Difficult to describe what the class does in one sentence.
- Changes needed to be made in the class for more than one reason.
- It has more than seven methods.
- Overall flog score exceeds a total of 50.
Sandi’s recommendation: Classes can be no longer than one hundred lines of code.
A God class is found in a lot of applications and is symptomatic of improper planning and poor architecture. A God class is any class that seems to know almost everything about an application. It has too many references to other models and is in turn referenced from too many places in the application. Most applications have two God classes: the user, and the central focus of the application.
Methods suffering from feature envy contain logic that doesn’t actually belong in the current class. Moving the method (or the affected portion of a method) to the appropriate class improves maintainability, makes the logic easier to reuse and reduces coupling.
- Repeated references to the same object
- Methods containing a class name in their own name.
- Existence of private methods that accept the same parameters.
Long Parameter List
Ruby supports positional method arguments which can lead to unwanted long parameter lists.
- The method has four or more arguments.
- It requires large amounts of setup during isolated testing.
Sandi’s recommendation: Pass no more than four parameters into a method. Hash options are parameters.
This is a code smell that makes changing and maintaining code a nightmare.
- The same change needs to be made across several different files and lines.
- Difficult to modify code as it can get hard to keep track of the exact change in different locations
Software is meant to be read, understood and modified by humans. Names are supposed to communicate what the method/class/variable is all about, therefore a complicated/shorthand/random name completely negates the purpose.
- Difficulty understanding the purpose of a method or a class from the name.
- Methods/classes which have different functionalities but similar names.
Callbacks provide convenient hooks and are easier to implement. Hence often abused in an application. But as the application grows, it becomes increasingly difficult to understand and maintain callbacks as complex callback chains can often be unpredictable. Models that incorporate too many callbacks are often harder to refactor and prone to bugs.
- Callbacks that contain business logic like processing payments.
- Callbacks that need to be invoked conditionally.
Get to know about Rently at https://use.rently.com/
To learn more about Engineering topics visit – https://engineering.rently.com
Senior Software Engineer
Associate Software Engineer