Step up your code with Clean code -2
They say when you practice a skill, you start loving it! The same happened to me! Thankfully our team here at Sahaj follows practices of code review before merging it with the main branch. Initially, I used to get a lot of review comments for modification in the way I had written code. Understanding the “Why” behind each review comment gave me a better understanding of writing clean code. My aim nowadays is to minimize the number of review comments on my PR! If there is none, I am the happiest creature! As with every individual, I am also learning each day. After writing my first blog on Clean code, I think now is the time, I want to share my learnings further on this. I thought of mentioning the learnings that I got through review comments or discussions.
- Variable naming conventions:
- Never use short forms for the names of variables.
-> Never use pm for perimeter - Never name variables just to satisfy the compiler.
-> Never use variable names as length2, length2 - Avoid using words with the same meanings for different variables.
-> FileData and FileInfo both sound similar - Include units of a measurable entity to its variable name
-> Use timeInSeconds as a variable name rather than developer figuring out that time is in seconds - Add sufficient context to the name rather than telling the detail about it through variable names.
-> The name should be as as long as it makes it easily understandable - Have consistency when it comes to defining operations for a particular task.
-> if we are using fetch as the term to get data, we need to be uniform with that through out the codebase.
2. All about functions:
- Functions should be really smaller.
- One function should do one task only. If your function is doing two or more tasks, you should probably split it into two functions.
- The code inside the if / else blocks should be only one line long. If it’s more than two/ Three lines it should mostly be a function call.
- The maximum number of arguments for a function should be 3 or 4. If there are being more than the limit, it probably can be a class of its own.
- The function should never modify its input parameters.
- Extract Try/Catch blocks into one function. Error handling Is one responsibility, hence should be one different function.
3. All about Classes:
- Classes should maintain encapsulation.
- Classes should follow the Single responsibility principle.
- Name of Class should tell its responsibility
4. Code Formatting:
I initially thought code formatting is not that important, but when you work on a large codebase, and if the code is not formatted well enough, it’s definitely going to be irritating.
Few of the things I noticed in this regards are:
- Follow the same indentation level throughout the codebase.
- Variables should be declared as close as possible to their usage.
- All the private methods should be at the lower level in the class.
- A single line should not have more than 120 characters.
- There should be spaces between commas, operators.
- Have one same check style.xml for the entire project, so that for every change, good formatting rules are followed.
- Remove the unused imports.
I am still exploring and learning how to write clean code. I would definitely suggest reading “Clean code developer checklist”.
