Principles from Clean Code and The Clean Coder

Henrique Siebert Domareski
5 min readJun 5, 2020

Some time ago I found on Amazon an ebook from Robert C. Martin, with the ‘Clean Code’ and ‘The Clean Coder’, both together. I had already read the Clean Code in the past, but I hadn’t read it yet the second book, ‘The Clean Coder’. So I bought this ebook and started to read ‘Clean Code’ again, and also read ‘The Clean Coder’. Some days ago I finished the reading of those two fantastic books and I would like to share some points about them.

Image source: https://images-na.ssl-images-amazon.com/images/I/41jEbK-jG+L._SX258_BO1,204,203,200_.jpg

Clean Code’ says about good practices in coding, giving you helpful principles to you develop code with quality, consistency and make well-written code. Some points are:

  • The importance of using meaningful names in your variables and methods. The name should reveal the intent of the variable/method. This will make it easier for other developers to read and maintain the code, and also for yourself. Doesn’t matter if the name will be long, it’s better to have a longer name than a short enigmatic name or a long descriptive comment.
  • Write functions/classes that do one thing. This is also about the letter ‘S’ from the SOLID Principles, the ‘Single-responsibility Principle’, which says that your class/method should have one, and only one reason to change, that is, your class/method should have just one responsibility, it should just do one thing and should do it well.
  • Write small functions. Functions should hardly ever be more than 20 lines. Big functions can probably be doing more than one thing.
  • Write functions with just a few (or none) arguments. Using many arguments in a function can make your code more difficult to understand and also difficulties to test. So avoid using more than three arguments, and if possible, use less than that.
  • Don't repeat yourself (DRY principle). You should not repeat code, duplicated code become a mess.
  • How to write (or don’t write) comments. If you write good code, probably you will not need to use comments (except for some specific cases, for example when it is necessary to explain some complex business rule), because any developer who read your code will understand it.
  • Unit tests. Your tests should be readable, be clear, be simplicity and be expressive. Tests are really important to the project because with them it’s easier to maintain the code and you can guarantee that the code works. If you have tests, you don’t need to be afraid of making changes in your code.
Image source: https://images-na.ssl-images-amazon.com/images/I/51+NUIgEc9L._SX258_BO1,204,203,200_.jpg

The Clean Coder’ says about being a professional. Some principles explained in the book are:

  • Responsibility. As software developers, we must take responsibility for our job. We need to be concern about the quality and cleanliness of the code, unit test, delivery dates, and so on.
  • Commitment. A professional should be a commitment to his tasks. If he says he will deliver a new feature in 1 week, this means one week and not 2 weeks. We should be a commitment to what we say. A professional just make commitments if they know they can achieve them.
  • Helping others. A professional is someone who helps the team. He is not only concerned about himself, but he is also concerned about helping the team, and teach other developers.
  • Humility. A professional must be confident in his own abilities, but also need to be humility. Even an experienced developer, can also learn with others.
  • Practical. This is something that you do when you are not getting paid. Professionals practice because they care about doing the best job they can. A professional also spends time to practice and study. Even if you are an experienced developer, there are some stuffs that you could improve or new things that you can learn.
  • Concern with tests. The tests are a way you can guarantee that your code works. You can not test everything every time you change something, unless if you have automated unit tests with very high coverage. So if you don’t have tests in your code, how can you consider yourself to be a professional if you don’t know if your code works?
  • Time management. Uncle Bob (the author of those books), says that programming is an intellectual exercise that requires extended periods of concentration and focus; and says that focus is a scarce resource, rather like manna (like the RPG Dungeons & Dragons), and after you have expended your focus-manna, you have to recharge by doing unfocused activities for an hour or more. You can achieve it by doing things like sleeping, doing exercises, drinking coffee, and others. The fact is that sometimes you need to stop, to recharge your ‘mana’.
  • Concerned about the quality. A professional is concerned about all the code in the project, and not just only with the code that he wrote. If you find a bad code, you can clean it.

Of course, those are just some points, there is much more in the books. So if you are interested in learning more about it and you care about writing good code and being a professional, I strongly recommend the reading of those books.

This is the link to buy this ebook on Amazon: https://amzn.to/2Y3IH5f

Image source: https://m.media-amazon.com/images/I/51J+Z3wDJkL.jpg

--

--