Thoughts on Clean Code

Clean Code Cover

Towards the end of May, I started reading Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin. The book is broken down into three sections. The first is described as the “feel-good” section, where the rules are introduced and detailed. The second section of the book focuses on example code (Java) and refactoring it. The last section covers “smells and heuristics.”

The suggestions and explanations have been really eye-opening. In particular, I really enjoyed (as much as you can enjoy becoming increasingly disappointed in your work) reading the chapter on functions. I’ve realized how terrible I’ve been to myself and my team members by having so many levels of abstraction within our code. Aside from the concepts that are brand new to me, there are things that have “felt” wrong, but I never pinpointed why. An example of this would be DocBlocks that feel redundant: basically a sentence form of what the code is clearly doing. The reason it feels redundant is because function naming conventions should already clearly state what the function does.

I’ve been taking a ton of notes (mostly in the form of checklists) and have spent a decent amount of my free time cleaning up comments and naming conventions. Once those are cleaned up, all of my attention will be focused on reducing my levels of abstraction within blocks and functions.

As I get further along in the book, I’ll try to keep up with blog posts with some examples of code that I’ve cleaned up.

Was this post helpful?