Writing software is hard. There’re only a few ways to do it right and there’re many ways to do it wrong and make our lives hard.
In this article, we’ll look at some ways to write bad code by looking at a few codes smells.
Duplicated Code
Duplicated code is almost always bad. If we see the same code structure in multiple places, then we’ve to change it by unifying them and then referencing that piece of code.
For instance, if we have 2 expressions in 2 methods of the same class, then we can put the duplicate expressions in their own method.
When we have 2 expressions in 2 sibling subclasses, then we can put the duplicated expressions in the superclass.
If we have duplicated code in 2 unrelated classes, then we can put them into their own class or top-level function if the language allows us to write standalone functions.
Long Method
We can divide a long method into smaller methods that do one thing.
This way, we can read each method much more easily and know what they’re doing.
The longer a procedure, the harder it is for us to understand. Therefore, we should decompose them into smaller methods that are a few lines long.
We can also clean up our code by replacing long expressions with shorter ones.
For instance, we can replace JavaScript loops with array methods that do the same thing.
Large Class
A large class is trying to do too much. It may have lots of instance variables and methods.
Therefore, we should reduce them by splitting one big class into smaller classes that do the same thing.
We can extract the big class into smaller classes that do one thing only.
This way, we keep things easier to read and understand.
If we’re writing web apps, then we need to separate presentation logic from the business logic, for example.
Then we have 2 pieces of code that do their own thing. We also have to keep them loosely coupled by not referencing too much of each other’s implementation.
Long Parameter List
Long lists of parameters in functions need to be reduced. If we have more than 5, then we’ve to find ways to reduce them.
The fewer parameters we have, the better the function is.
More parameters mean it’s easier to make mistakes when passing them in,
One way to do that is to put everything in an object, then we don’t have to pass different things in as separate parameters.
Divergent Change
If we have multiple classes that change in different ways but share the same code, we can move the common code between them to one location and then reference them there.
This way, only the code that’s different is are in their own place and the common code stays in one place.
Shotgun Surgery
Shotgun surgery is changing different code in different classes. They’re then all hard to find and it’s easy to miss an important change.
We can deal with this by moving the shared code to their own location and we can make the change to that part all at once so that we don’t have to make small changes everywhere.
Feature Envy
This is a code smell where we get all data from many different places and put them together to get some results.
This makes coupling between classes tight and makes any changes risky because of that.
Instead of referencing many parts of our code, we should instead reduce the coupling by creating a method to reference all that code in the originating class and then use that method to get the result that we want.
The data is usually all in one class, but we just didn’t both to access them in a loosely coupled way.
Data Clumps
We may often see the same few pieces of data together in many different places.
If the clumps of data appear as fields, then we can turn those clumps of data into its own object so that we can just reference them anywhere.
If the clumps of data are passed in as arguments to functions, then we can combine them to an object parameter to avoid passing them in as multiple arguments.
Instead, we have one object argument that we can use anywhere/
Conclusion
As we can see, there’re many ways to write code in messy ways.
Duplicate code should be combined. Multiple clumps of data should be combined into one so that we can use them together.
Tightly coupled should be mostly decoupled to reduce risks of breaking things.