Become a professional software developer needs a lot of study and effort so if you want growth you need to improve the quality of your code, the maintainability, readability and decrease rework of your projects. I suggest you learn more about clean code.
In the Clean Code book, we can find a lot of hints and good practices about making a better code, besides each language or framework have its own rules and a long list of things to study. To help you start your journey, I summarise four rules — that I got from the book — to design projects.
Runs all the tests
Have a comprehensive number of tests developed and passing seems obvious, because everyone is expecting the system is working at the first place, but to write unit tests the code must follow the well-known high-quality design principles such as simplicity, single responsibility, low cohesion and more.
Remarkably, following a simple and obvious rule that says we need to have tests and run them continuously impacts our system’s adherence to the primary OO goals of low coupling and high cohesion. Writing tests leads to better designs.
A system that cannot be testing probably shouldn’t be developed. Think about it.
Contains no duplications
Duplications can have many forms, lines of code that are the same or similar or different methods to do the same job and when your project has duplicated code also you have duplicated work, duplicated risk and unnecessary complexity. The secrets to avoid duplications are refactoring, refactoring, refactoring and follow the SRP.
Expresses the intent of the programmers
Writing code that expresses the intent of the programmer that another person can easily understand is important for many reasons, especially for projects with long life terms that need maintenance.
As much clearer is the author, as less time others will have to spend to understanding it. Here are some hints:
- Choose good names: we need to hear a class or function name and not be surprised when discover it's responsibilities.
- Keep classes and functions small: small classes and methods are usually easy to name, write and understand.
- Using standard nomenclature: using Design patterns, for example.
- Keep testing as documentation by example: when another person reads the tests should be able to get an understanding of what is all about.
Minimizes the number of classes and methods
It may sound controversial but is not. In an effort to make our classes and methods small, we might create too many tiny classes and methods. The least rule suggests we keep these numbers counts low.
It’s import to say that the 4 rules are ordered by priority and the last one only applies if it satisfies the previous ones.
The fourth rule doesn't suggest we should have only a few classes and methods but if there are too many pieces we won't be able to see the whole picture and understand the application context. Besides that, this rule means we should remove all code we don't need and decrease unnecessary complexity and maintenance.
Conclusion
The content shared in this post is just the base what every developer needs to know to design project, but I hope it had helped and inspired you to learn more about Clean Code — I thoroughly recommend the full reading of the book.
Keep coding and thanks for reading ;)
Top comments (0)