Several signs determine the quality of a project. Stability, evolution… and if the project has the code clean.
In the following article, I list 6 tips that make a project clean.
Imports
The imports are the first thing we see when opening a file. Even if most of the IDEs compress them, keeping the imports clean is important. Because when working with Merge Requests, a lot of times, conflicts occur in the imports.
Here are some few tips to keep them organized:
- Remove unused imports: this reduces the amount of imports, of course, and reduces the classes loaded in memory.
- Don’t use * (wildcard) for imports (only if more than 5 imports): overusing the wildcard for imports is like the previous point, importing unnecessary classes.
- Sort the imports: this is the best tip to avoid conflicts when merging.
Most of the IDE already do this by default. But some need more configuration to do it correctly.
Methods Short
The methods are the key point of a clean code. All the logic is located inside the methods. Keeping them short and readable makes the whole application easier to read.
I always try to keep all my methods under 20 lines of code. When I pass this limit, I try to export some of the logic out to another method. This makes my methods with a single purpose.
Most of the code analyzers also show another important metric, the cyclomatic complexity. It’s a metric which depends on the loops and if-conditions. The more there is, the higher the complexity. I always avoid a complexity over 10 points.
Avoid Utility Methods or Classes
Another sign of low-quality code is utility methods or classes. It’s easy to refactor some duplicated code and put it all into a utility class. But this can quickly become harder to maintain.
Utility classes are static and harder to test and mock. Instead, I always try to use an Object Oriented solution or mapper and parsers. It’s easier to test and mock.
Use Get and Set for Getters and Setters
I’ve always said: to have a well-structured project, a good naming convention is mandatory.
The verbs Get and Set should only be used for getters and setters. This means that those verbs are used for methods with no logic behind them.
If my method has more logic, I have plenty of other verbs to use: fetch, find, calculate…
Use Verbs to Name Methods
Following method naming, all the methods should use a verb. As methods are written to do an action, verbs are used to name the action.
If I need two verbs to name my method, maybe it’s time to split the method into two separate methods.
Variables Should Be Singular Nouns
If the methods are named with verbs, variables should be named with nouns. Singular nouns.
One variable, one singular noun. Because one variable will contain only one value.
Use plural only for lists or maps (vehicles or vehiclesById).
For boolean values, I have two alternatives: using the past participle or the is verb (activated or isActive).
Finally, avoid repeating the class name into the variable name. If the class is Car, avoid carFuel, carPower, carCapacity…
Conclusion
Those tips must not only be used by the team leader or senior developer. Those tips should be written in the documentation of the project, and all the developers should be aware of them and follow them.



Leave a comment