Reading and Learning 'Clean Code' by Uncle Bob #Day_3

On Day 1 I introduced you all to this series of CLEAN, and why we should bother about it. On Day 2, I shared my interpretations from the first chapters of the books I'm currently reading and learning from, namely 'Clean Code' and 'The Clean Coder'. Today, I'm going to take just one chapter from the first book and on Day 4 I'll take a chapter from the second book. I would like to keep my blogs short and brief. So let's jump in right away into the second chapter of 'Clean Code'.

Chapter 2: Meaningful names

Because we all are smart creatures aka humans, we associate a lot with what we call our stuff. When a baby is born, there could be a whole debate going on in the family on giving a name to the baby, They want a name that has beautiful meanings and then they can shape their child's personality according to the name. This is no different from what we name our classes, methods, functions, variables, etc. Because that name should be meaningful according to the task it's going to perform. That's why no one would name their child Hitler. Here's the sum-up of the chapter:

• The names of variables aren't suitable with just a random combination of 2-3 characters or maybe if it is making sense like, var1, var2, var3 etc., it is failing to clear the intent. What about name, age etc.? (pffff..Aqsa we know that much). Ok, what about customerName, customerAge? Or what about employeeName, employeeClient? A few extra meaningful characters in naming can provide us with a better understanding of what's going on. Now we know the variable will store the name and age of the customer, or in the latter case it'll store the name of the employee and perhaps the name of the client that particular employee deals with. employeeClientID gives more information about what this variable is going to store. This is not just applicable to variables but to anything else we have to choose the name for.

• Names must be straightforward and one should avoid disinformation, I'm going to take an example from the book itself for this one (yes the example in this first point is created by me, I'm creative), accountList should be account and list only if it is actually a list because, to us, the list really means something.

• Names should be distinct and not overlapping in meaning, which would lead to duplication of the interpretation. We don't want to duplicate literally as well. This shall create redundancy and irrelevancy. Making names different but still having the same meaning is just creating noise words. Making little changes in the names just because one was already in use, we don't want that. Make distinctions.

• Your code will be seen by other people as well, they would also work on it or work with it. So avoid mental mapping, and help in reducing extra efforts by not using different names for the things names are already known for. Conventions and traditions help in quicker understanding and avoid extra effort by the reader to do translation and mental mapping. An example could be that we use 'i' for index, imagine using 'p' and the reader of your code is mapping it to 'i' in his mind.

• Pick one word per concept, don't use synonyms.

• Use names related to the solutions domain, this could be very helpful in understanding the code quickly, If that's not working well you can also take names from the problem domain.

• There should be moderation, we don't want too long names like including the prefix of the class because that could again be unnecessary or, even worse, give rise to confusion. We also don't want too short like 'state', what state? 'addrState' makes better sense, as now we can understand that the name of the state is actually the part of the address. So we should provide context without making it unnecessary.

Now I'm gonna share quick tips I skimmed out.

• Class names should be nouns and method names should be verbs. I hope this makes sense to you, it'll if you understand what a class is and what a method does.

• Use pronounceable names (this was pretty obvious but try speaking the names out when you assign it).

• Use searchable names, single character names or a very very small name like 'ji' can be difficult to locate.

• You shouldn't be adding a lot of comments to explain what's going on rather your naming skills should do it.

This is my summary of the chapter. I find this truly helpful, These are just some small tips but that's how we make a good improvement. Ponder upon these, you can even come up with more solutions or more ways to do the naming procedure better. Customize your own procedure and share it with your peers. Work and collaborate and I hope these tips help you to smoothen the process of creating and collaboration. On Day 4, I'm going to take chapter 2 of 'The Clean Coder' called 'Saying No'. Until then, Happy clean coding.