Step up your code with Clean code -2

Picture Credits: Waverley Software

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.

1. 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”.