Book recommendation: Clean Code

Clean Code: A Handbook of Agile Software Craftsmanship

Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.

Introduction

Even though I read the Clean Code book a while ago and there are a lot of reviews already available, I couldn't resist writing about it a bit.

The Clean Code book makes you feel like why didn’t you come across it before. It's all about writing high quality code, and how to judge the quality of code. With magic points, Encouraging the reader to write natural language code which is understandable by human brain smoothly, with any syntax of any language you use in you project.

As you can't see the right thing without knowing the wrong, the book presents a code that is ugly, hard to read, understand and maintain, then Uncle Bob led the way step by step to refactor that code and transform it into clean, readable, understandable and maintainable code.

Clean Code

No doubt about that messy code can work as long as it does what it's intended to do without logical errors. But this broken windows mentality leads to waste countless hours and resources to update or modify the code.

However, the book gathers thoughts on good code and its various attributes from a number innovators and authors such as Kent Beck, Bjarne Stroustrup, Dave Thomas, etc.

To make the code easy to read, it gives you the golden advice of using intention-revealing names. emphasize to NOT use member prefix such as _ or m_.

And for functions and methods, they should be small and cohesive. It also suggests using single level of abstraction to facilitate reading code from top to bottom.

Single level of abstraction Principle (SLAP); it means that every function / method in your codebase should deal with just one level of abstraction and do one thing, just like Single Responsibility Principle (SRP) mentioned in my previous article about SOLID Principles

In order to explain yourself, you should write good comments that focus on intent and is not redundant and misleading.

Discussing error handling, it encourages use of exceptions rather than return codes or error codes. It prohibits use of checked exceptions as it violates open/closed principle (one of SOLID principles, read here). It also discourages returning or passing null.

It pays great attention to unit testing and test-driven development (TDD) which is one of the main phases of the development cycle.

Fun thing that the book includes a lot of blank pages with "This page intentionally left blank"; they are after each chapter; to make you stop and think little more longer.

Annoying thing for me that the book contains large number of code examples (that I skip sometimes 😅🥹), which is wonderful for sure to clarify rules and advices and so on.

Conclusion

It's a must-read book for programmers, some of the outcomes of reading it, the ability to:

• Write good code and clean bad code.
• Differentiate between good and bad code.
• Increase your code readability.
• Build reusable entities.
• Get used to explain yourself by good comments.
• Build elegant functions and components.
• fit error handling to your code logic.
• Unit test for a shorter dev cycle.
• Practice TTD.

Thanks for reading! 😄