Why I decided to read ‘Clean Code’ and you should too

I am a shitty programmer. I don’t usually comment stuffs; my code is mostly redundant and I do things the bad-way. I knew this. I didn’t bother changing it. I could understand what I was doing. Until I couldn’t.

I am not a kind of guy who reads 426 pages of book in “clean code”. In fact, this must be one of the only technical books I have read front to back. Which implies I was really desperate to write cleaner code.

This all started when I decided to build something new. The initial rush and excitement of a new project is heavily underrated. It’s one of the fewer feelings that match with debugging your code successfully and making it run. This time around I wanted to go out of my comfort zone. Something a little complex than what I usually build. This meant more lines of code.

This wouldn’t usually be the problem but I don’t usually do large projects.

I started noticing I was being slow. I had too many bugs than usual and I had even more hard time debugging it.

A programmer’s code is baby to him. Everyone has to start from the bottom and what one learns at the beginning is what he believes. It becomes too late till he realizes it’s hard to admit your code sucks.

But I knew there was something wrong with my code. The more the lines in my code grew the harder it was to debug. Tests started failing even more. I needed to change something. And it was the way I code.

So, I frantically Google, reading almost every possible article on cleaner code. Every one of them seemed to mention the book Clean Code in one way or other. In fact, it was the most mentioned book in r/programming and YCombinator forum (aka hackernews). I decided to read the book. If the book is worthy of so many mentions, it must be something.

Here’s the book if you are looking to buy.

Clean Code: A Handbook of Agile Software Craftsmanship

And boy, that could be one of the best decision in my professional career. It’s not possible to go over every detail of the book, but these are the main highlights of the book from almost every chapter:

1. Clean code is elegant, simple, efficient, straightforward, crisp, clear, literate, readable by others, unsurprising, has minimal and explicit dependencies, has automated tests, minimizes the number of classes and methods, expresses its design ideas, handles errors, has nothing obvious that one could do to make it better, looks like the author has cared.
2. Use meaningful and informational names for classes and methods. The best way is to use nouns for classes and verbs for methods.
3. While defining functions, avoid nested structures as much as possible. Avoid using parameters; instead use member variables to take in arguments.
4. Comment as often as possible. Make clear comments and informative comments. When using APIs use comment the documentation section that you used.
5. Format your code adequately. Use a formatting tool and maintain the orderliness of your code so for better readability of your code.
6. Try following Law of Demeter i.e., call only methods of your own class, of objects you have just created, of parameters, and of instance variables, not
   further methods reachable through these.
7. When handling errors use exceptions or do-nothing objects rather than returning null.
8. Use the FIRST rule to write tests: Tests should be fast, independent of each other, repeatable, self-validating, and written before corresponding code.

I am no expert at writing good code; I still have a long way to go. But I definitely feel like the beginning of something. I have reduced my debugging time by 1/3 and I am proud of that.

. . .

Follow me on Twitter