The code quality rules
Tags: refactorit, codequality, tutorial, productivity
Published: 2022-08-08 22:25:08

What do we need to do and what we should avoid during writing the code?

I spent a lot of time understanding or finding some props and cons from different approaches that can be used in most projects. However, my suggestions are most oriented for the new project or project under refactoring, for developers who try to find a way of making the project more maintainable.

My suggestions have one goal - to make development easier. I mean you should spend less time making changes in the code or learning how the code works. All of my suggestion is not new, however, I hope you will find something new for you.

Let's start.


**Code should be simple.** If you see that you need to have a lot of conditions, flags, enums, e.t.c probably it is a signal that you are going in the wrong way. Complex code will become difficult to maintain or change after some time. As a result, it will increase the cost of supporting your project.


**Code should be testable.** It is not obvious when you write code, but you just could think if it is possible to use this class outside your system or if you will need to take some other components from your system to run your code. If you can use the class without other components (I mean you can replace them with mock in a simple way) it will be easier to test. Testable code usually has fewer hidden dependencies and is more stable. In addition, you will spend less time writing tests.


**Code should be decoupled.** It means that your classes should have fewer dependencies as it is possible. The same rule for modules. (of course, your project should be split into modules, let's talk about it a bit later). If a class has a lot of dependencies it said that your class doing a lot of work.


**Code should be short.** Make your code as smaller as it is possible. You should have small classes, small methods. Because it is easy to read, easy to understand, and easy to maintain. If your method has more than 40 lines it is a sign that your method doing a lot. I am sure that in most cases it is easy to split the huge method into a few smaller ones. The same about class. Of course, after splitting huge methods you will have a class with a lot of methods. In this situation, you have to extract part of these methods to another class and use this new class as a dependency. In this way, you will split responsibility between classes and it is awesome.


**Split your code into features.** The next thing that can help you keep your code healthy is splitting your project into modules. It depends on the type of the project, but it can be applicable to most types. Even if your project doesn't support modules you can split code by packages or folders, the most important thing is to split by features not only by layers (I mean split not only by class types, like network, UI, models). In this case, your components will be more independent, and changes in one feature wouldn't affect other features.


**Make refactoring.** Even if you and your team are writing perfect code always try to make your old code better. Because your project is changed since the time when this code has written and maybe now you can see a better way of writing some parts of this code.


**Create guidelines** of code style and general approaches in your project. Even if you work alone it helps you to follow the same approach in all parts of the code and will make changes easier after some time. When all project follows the same styles and uses the same approaches it improves readability and makes understanding code easier. Moreover, it will help new team members during onboarding to the project.


These are not difficult and obviously, rules can make a significant impact on the project code quality. As result, it will have an impact on the stability of your application and the cost of maintaining your project.