Digitop VNThe Three Laws of Readable Code
As developers, we strive to write code that is not only functional but also easy to understand and maintain. In this article, we will explore the three laws of readable code, which will help you to become a better programmer and make your code reviews a breeze.
Does Your Code Tell the Truth?
"Law 1: Write self-documenting code"
The first law of readable code is to write self-documenting code. This means that the code should be clear and concise, making it easy for others to understand what it does. A good example of this is a function that calculates the area of a circle. Instead of having a comment that explains what the function does, the function name itself should be descriptive, such as calculateAreaOfCircle. This eliminates the need for unnecessary comments and makes the code more readable.
Avoid Magic Numbers
The second law of readable code is to avoid magic numbers. Magic numbers are numerical values that appear in the code without any explanation. They can make the code difficult to understand and maintain. A better approach is to use descriptive named constants for these values. For example, instead of having a function that calculates tax based on a certain threshold, you can define a constant HIGH_VALUE_ITEM_TAX and use it in the function. This makes the code more readable and easier to understand.
Avoid Too Many Function Parameters
"Law 3: Avoid too many function parameters"
The third law of readable code is to avoid too many function parameters. When a function has too many parameters, it can be difficult to read and maintain. A better approach is to create an object that comprises all of these fields, and then use a builder to create the object. This makes the code more readable and easier to understand.
Conclusion
By following these three laws of readable code, you can write code that is easy to understand and maintain. Remember, the goal of readable code is to make it easy for others to understand what the code does, without having to read through a lot of comments or unnecessary complexity. By writing self-documenting code, avoiding magic numbers, and avoiding too many function parameters, you can make your code reviews a breeze and become a better programmer.
