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.
Primitive Obsession
Programming languages like JavaScript have 2 kinds of data. They’re primitive values and reference values.
Primitive values are the building blocks of our program. They store things like numbers and strings.
Reference types come in the form of objects. They store multiple primitive values and other objects all under one umbrella.
Objects ultimately have primitive values at the bottom of the object’s tree structure.
If we have a bunch of primitive values that are always together, then we can have an object to put them all in one package.
This way, we don’t have to deal with so many primitive values everywhere.
Switch Statements
Switch statements are conditional statements tat contains many cases indie them.
The problem is that there’re lots of duplication in switch statements.
If we have them scattered in different places, then we’ve to update our different switch statements so that we can change our code.
In this case, we should consider polymorphism instead of using switch statements.
Parallel Inheritance Hierarchies
This occurs when an inheritance tree depends on another tree by composition.
They maintain a relationship where one subclass of a dependent inheritance tree depends on a subclass of another inheritance tree.
This isn’t good since if we have to make a subclass of a class, then we’ve to make a subclass of another.
Therefore, we’re forced to duplicate the inheritance hierarchies when making the 2 classes.
We can eliminate this by moving the instance of one hierarchy refers to the instance of another rather than duplicating the inheritance tree for both classes.
Lazy Class
A lazy class is where we create a class that doesn’t have much in it.
In this case, we should remove it since it cost time and money to maintain an extra class.
Speculative Generality
If we don’t need anything now, then we shouldn’t add it.
Writing flexible code makes our code more complex and that will slow us down.
We should only add code that we need now and make it easy to change later.,
Therefore, we shouldn’t overengineer anything. If we have extra code that isn’t doing much now, then we should remove them.
We can spot them when those pieces of code are referenced by test cases. Then we know that they don’t provide us with much value.
Temporary Field
Temporary fields are ones that are only set in certain cases.
This makes the code hard to understand because we expected an object to need all of its variables.
If we need them, then we can extract them to their own class, so we only reference them when we need them.
Message Chains
Sending a chain of messages around our system isn’t great. We have a message having when something asks for an object and that object asks for another object and so on.
We may be calling a chain of getters or referencing a chain of variables.
In either case, the code is too coupled together with the implementation.
And it’s hard to navigate through the message chain for us to understand the code easily.
We should combine the chain into one so that we don’t have to so many objects.
Middle Man
Encapsulation is important. Therefore, we don’t want all our classes to know the details of another class.
However, we may go too far by introducing a middle man class that is only used to delegate calls to another class.
In this case, we can eliminate the middle man class and just call the code we need directly.
Inappropriate Intimacy
Classes can become too intimate and they know too many details of another class.
This isn’t good because too much knowledge means tight coupling. This means that when we change things in one class, we’ll likely break the code in the other class.
We should break them by removing the intimate code. Put any common code into their own class.
And we should avoid referencing any code that has the implementation details.
Subclasses may also know more than the parent class wants them to know. Un this case, we can hide those details by making them private.
Conclusion
We shouldn’t be obsessed with using primitive values. Use objects to group them when necessary.
Also, classes shouldn’t have too much knowledge of each other. We need encapsulation to losses coupling.
Parallel inheritance hierarchies are bad since they duplicate the inheritance tree.
