The concept of clean code was popularised by Robert C. Martin’s book ‘Clean Code: A Handbook of Agile Software Craftsmanship.’ According to him, reducing code duplication, achieving high expressiveness (simple and straightforward code), and creating simple abstractions from the outset are the actions that make code clean. To apply this concept in practice, this article will cover the following topics:
calculate_area_rectangle(), temperature_celsius, and class_car make the code easier and more efficient to read. booksArray. In this case, the variable name suggests an array and not a dictionary, which is the true content of the variable. getSummary(int id) and getSummaryInformation(int id), it is not clear the difference between one method and another. The reader of the code is forced to check the implementation of each function to understand the return of each one. first_fruit is much harder to find than the variable first_fruit_banana because first_fruit can list all variables of different fruits. HolyHandsGrenade should do? Sure, it’s funny, but maybe DeleteItems would be easier to understand. The first rule for functions is that they should be small, around 20 lines at most.
Functions should do one thing only, and they should do it well. One way to know if a function does more than ‘one thing’ is if you can extract another function from it based on its name, which is not just a reformulation of its implementation.
Functions should either do something or answer something, but not both. Your function either changes the state of an object or returns information about it. Doing both tasks often leads to confusion.
The ideal number of parameters for a function is zero. Then comes one, followed by two. Whenever possible, avoid three parameters, as more than that can complicate code understanding and maintenance. This principle, derived from Robert C. Martin’s book ‘Clean Code,’ emphasises the importance of keeping functions simple and focused on a single task. For example, instead of passing multiple parameters to calculate the average of a list, it is preferable to pass only the list itself, making the function more cohesive and easier to understand.
These parameters are ugly. Passing a boolean to a function is certainly a terrible practice because it immediately complicates the method signature, showing explicitly that the function does more than one thing. It does one thing if the value is true, and another if it is false. An alternative to using boolean parameters would be to create two functions, one for each case.
The first rule for classes is that they should be small, and the size of the class is measured by its responsibilities. According to Robert C. Martin, the name of a class should describe its responsibilities, respect the single responsibility principle, and that our systems consist of many small classes, not a few large classes. Each small class encapsulates a single responsibility, has a single reason to change, and contributes to a few others to obtain the desired behaviours in the system.
The author of Clean Code states that we have to structure our systems in a way that we mess up as little as possible when we update them. In an ideal system, we would incorporate new features by expanding the system and not by changing the existing code. In other words, we need to support the key class design principle, known as the Open-Closed Principle (OCP).
This principle suggests that a class should be open for extension but closed for modification. In other words, we should be able to extend the behaviour of a class without having to modify its original source code. For example, if we have a class that calculates the shipping cost for different types of products, we can extend this class by adding new specific implementations for each type of product without modifying the existing class. This keeps the code more flexible and less prone to introducing bugs when new features are added. For example, we can have a class ShippingCostCalculator with methods to calculate the shipping cost of different types of products, such as calculatePhysicalProductCost(), calculateDigitalProductCost(), etc. If we need to add a new type of product, such as a perishable product, we can extend this class by adding a new method, calculatePerishableProductCost() without modifying the existing methods.
According to Robert C. Martin, the proper use of comments allows us to compensate for our failure to express ourselves in code. We should use them because we don’t always find a way to express ourselves without them, but their use is not a reason for celebration. So, when you find yourself in a situation where you need to create a comment, think carefully and see if there is no way to express yourself through the code itself. According to the author of Clean Code, the older a comment is and the farther away from the code it describes, the more likely it is to be wrong. The reason is simple. It is not realistic for programmers to keep them up to date. The author also states that one of the most common motivations for creating comments is bad code. Better than inserting a comment is cleaning up the code!
However, certain comments are necessary or beneficial, such as:
There are also comments that should be avoided:
To ensure that your code is well formatted, you should choose a set of simple rules that govern your code and then apply them consistently. If you are working in a team, then everyone should agree on a single set of formatting rules. Currently, there are automated tools to help apply these rules.
The author of the Clean Code book recommends indenting the code. According to him, indentation is a way to make the hierarchy of scopes visible by indenting the lines of source code according to their position in the hierarchy.
In summary, clarity in choosing names for functions, methods, classes, modules, and variables is crucial for understanding and maintaining the code. Avoiding puns, false clues, and funny names, while prioritising meaningful and pronounceable distinctions, not only facilitates reading but also reveals the underlying purpose of each element. Just as in writing an article, where organising thoughts results in clarity, carefully structuring code makes it readable and robust at the same time.
In the next article, we will address topics such as error handling, unit testing, and other important aspects in the pursuit of excellence in clean code. Don’t miss it!