During my first internship, I was asked whether or not I had read Robert C. Martin’s Clean Code. I had no idea what this book was about, but it later became my “must-read” for every developer.
In my first developer’s job, I had to maintain a program that was bought from another company. The code was very sloppy — it took me days to understand some of the functions. Another colleague gave up after looking at it and asked to be assigned to another project. As we were using GitHub, I could see the names of the program’s developers. I would never recommend them to anybody.
Later, as part of the application process for my current developer’s job, I was asked to code a small task. I was working so hard, trying to ensure the best functionality. The developer who had to evaluate this task later told me that he didn’t check my code — he just noticed that I wrote “README.md” and the names of my classes/variables were very easy to understand. I got the job.
In this article, I provide quick tips that are most important in order to write good code.
1. Structure
Before even starting to write any code, think about your program: classes, functions, structures, and so forth. Use packages and do not add too many classes to one package unless the classes fit within the same category. The more you plan, the easier it will be to keep writing your code — otherwise, you will have to restructure and refactor your code in the future.
2. Naming
You may say it’s obvious and everybody knows that good naming of classes, methods, and variables is very important. Yes, maybe…but don’t forget about it when you write code. You can always change RspValidation.java to ResponseValidation.java or print() to printResponse(). Names of variables should have their intents. I hope that I never see String asd in my programs.
Finding correct names and words for your code helps to avoid additional comments regarding explanations about the code. Having said that, I suggest writing explanatory comments for tricky methods or places with non-standard implementations. Such comments might explain business case or something else that might be important for the developers who will maintain it.
Don’t forget to use camel cases for Java code. Class names should start with a capital letter (please).
3. Solve a specific problem
If your class name is ResponseValidator.java, make sure it is only responsible for response validation and nothing else. If you want to add something else, create another class, or rename it.It is a good practice to have only one public method in the class. Everything else (private methods) should help to achieve the goal of this class.
Your method has to solve only one problem. Avoid writing big methods, because other developers might find them difficult to read. Decompose your method into a few perfectly named methods — it will be easier to test them, too.
4. Method parameters
Avoid using many parameters in method as it might be difficult to work with a method that has many parameters.
For example:private void addUserInformation(String name, String street, String houseNumber, String city, String country).
Idea for refactoring:private void addUserInformation(String name, Address userAddress).
5. Duplication
If two of your methods have repetitive code — extract it to the third method or a separate class, and use it for all the repetitions. Some developers say that it is easier to see everything in one method, but I think — less code, no repetitions, easier to maintain, and avoid bugs. The best IDEs have the ability to extract, in two clicks, the repetitive code into a separate method.
6. Hardcoding
Avoid it. I know… it is so easy to hardcode something when you are in a rush. But heavily hardcoded code is so difficult to maintain and leads to bugs and mistakes. As much as possible, use constant classes, .yml/.properties, generics, or whatever your team approves.
7. Logs
I once had to maintain the API, which was very well logged. Nobody from the company was acquainted with this code because it was written by a developer who left the company. I was also a stressed new employee.
On my second day in this company, a frustrated user called and told me that the API crashed. I checked the logs on the server. The logs were so well written that I found the bug in only a few minutes. I am still impressed with the developer who wrote this API; it saved me many hours.
I have provided the most important rules to keep your code clean. It looks easy, but even senior developers have to review their code to ensure it is understandable and readable. Just like any pedant, you can clean it to perfection — but don’t forget to evaluate project terms and priorities!
Photo by Jesus Kiteque on Unsplash
Sincerely yours, Hard Freedom.