Learnings from — Clean Code: A Handbook of Agile Software Craftsmanship

Presently, I am engrossed in “Clean Code,” a book that delves into the realm of best coding practices. I find myself pondering how beneficial it would have been if I had encountered this book a few years ago, as it encompasses numerous great principles that could have significantly impacted my coding journey.

The memories of my training days at Infosys, where I was introduced to programming in C, Java, and various other software technologies, still linger vividly in my mind.

As an ECE graduate, and not from a renowned engineering college, my college experience didn’t provide me with substantial exposure to coding. Instead, I resorted to memorizing a list of programs solely to pass the exams.

Why would a senior professional with 15+ years of experience, who could be focusing on management or strategy books, choose to be interested in reading about coding practices?

However, code is the foundation of our work, especially when managing a team of engineers with varying levels of experience (0–10+ years). Code reviews play a pivotal role, but knowing what to review and how to conduct these reviews is essential. This is precisely why understanding industry-wide best coding practices becomes vital for a manager. It enables you to enforce these practices within your team effectively.

What I’ve noticed in my numerous code review sessions is that less experienced team members tend to be receptive and open to learning, making it easier to guide them towards writing better code. However, some more senior team members occasionally go into a defensive mode, often saying, “We have a lot of work; we’ll do it later, sir.” This attitude leads to technical debt, and since we rarely get dedicated time to refactor code, it results in messy and unmaintainable code.

Now, let’s delve into the key takeaways or lessons learned:

Meaningful Names: Just like when a new baby is born into a family, and every member starts looking for meaningful and trendy names, the same principle applies to treating your code as your “baby” — it deserves a meaningful name too.

1. In the context of coding best practices, it is recommended that a class name should be a noun, while a method name should be a verb. This naming convention enhances code readability.
2. Regardless of whether you are naming a variable, class, member variable, or any other element in your code, ensure that the name reflects its context and usage. Even if the name ends up being long, what truly matters is that it conveys a meaningful story about its purpose.

Class x {
   int x;
   int y;

   int mult() {
       return x*y;         
   }

}

int d; // start time
int f; // end time
Int g; // delta time

// Instead
int startTimeIndays;
int endTimeIndays;
int differenceBetweenStartAndEndTime; 

Upon inspecting the code snippet above, it is challenging to deduce the purpose of the multiplication operation or the reason behind it due to the lack of meaningful naming conventions.

3. Names should be pronounceable, just like any other word in the English language.

4. Opt for searchable names in your code. When debugging or navigating through the code, the ability to search for classes, methods, or variables will prove beneficial, while the lack of searchability can cause inconvenience and frustration.

5. Avoid mixing names with language reserved keywords or operating system reserved keywords. It can lead to conflicts and unexpected behaviors in your code.

6. Avoid using the “m_*” prefix for member variables. Instead, aim to create readable and appropriately concise method and class names.

public class Product {
 
   String m_dsc; // discription
    
   void setName(String name) {

          m_dsc = name;
   }

}

// Instead
public class Product {
 
   String description; // discription
    
   void setName(String description) {

          this.description = description;
   }

}

7. When dealing with interfaces and their implementations, it is common to prefix “I” before the interface name. However, a better approach is to avoid the “I” prefix for the interface itself and use it only for the implementation. For instance, rename “IShapeFactory” to “ShapeFactory” and name the implementation as “ShapeFactoryImp”.

In the next segment (part 2), we will delve into functions/methods…

More: https://ajhawrites.blogspot.com/2023/08/learnings-from-clean-code-handbook-of.html

Follow me here as well: https://hubpages.com/@ajhawrites