*dusting blog*
*coughs*
Hi there! It’s been months since my latest post commit here, work life sure can be tight 😅 After two tutorials, let’s try some different type of commit, shall we? This time, I want to share about a book that changed the way how I code.
It was on my early days in Ice House. Some of our higher-ups just came back from US and brought technical books for us. I was reading a copy of The Pragmatic Programmer at that time, so I didn’t really looked at the new books. After a few days, Ridhwan handed a copy of Clean Code to me, and said this:
Check this book out, do. My code structure changed a lot, even only by reading a few chapter of it.
I took it with a so-so feeling. I was reading the Pragmatic Programmer, and that book made me feel worthless. It was full of best practices that I haven’t done (yet), so full of it that I was confused where should I begin with. I was unsure whether I can take something practical out of Clean Code. I was afraid (duh) that it will make me feel worthless again. Yet, I ended up reading it. It was recommended by the prodigy*, so… why not?
I read the introduction (it suggests amazing measurement for code quality) and the first chapter, and BAM – these paragraphs pops out:
I know of one company that, in the late 80s, wrote a killer app. It was very popular, and lots of professionals bought and used it. But then the release cycles began to stretch. Bugs were not repaired from one release to the next. Load times grew and crashes increased. [ … ]
Two decades later I met one of the early employees of that company and ask what had happened. The answer confirmed my fears. They had rushed the product to market and had made a huge mess in the code. As they added more and more features, the code got worse and worse until they simply could not manage it any longer. It was the bad code that brought the company down.
– Chapter 1, Clean Code, Robert C. Martin (emphasis added)
Those paragraphs stuck in my head, even now. As a fresh graduate, those lines didn’t struck me because I know my code is bad, but because it almost fits with the symptom on my side project on that time – Swift Notes on Blackberry 10.
At that time, our Swift Notes team received a lot of positive feedbacks from our users (thanks to Arnold heroic efforts for promoting it! 😆). We got a lot of feature suggestions, some users even willing to pay for it. Unfortunately, I was barely able to deliver any of it. These things keep happening:
- Bugs reappearing every time I add a new feature. Thank God that Arnold was a rigorous tester!
- Source code files became awfully long and I need to jump between multiple lines to know what’s going on in my old code.
- I had a hard time implementing new business logics, let alone fancy animations.
I grew tired from this vicious cycle, that’s why I decided to read through the Clean Code book – hoping that I could prevent the same fate on Swift Notes.
What it’s all about
After that hooking introduction, Uncle bob asked several experienced programmers (which almost none of them I knew before) about the definition of clean code. It turns out that there were different opinions about it, but there is a similarity between them which is code readability. Be it efficiency, simplicity, or lack of surprise, all of it boils down to code readability.
Just like any form of writing, computer code was meant to convey a message. Some of us may think that the main purpose of code was to send a message (read: instructions) to machine. While this is right, it is worth mentioning that the code is also a message for other people about instructions to the machine. This means that the code should not only understandable for the machines, but for us humans too. That’s where clean code kicks in.
Notable examples
The introduction and first chapter was full of philosophical quotes and reasons about why we should write clean code. After those two, the book was full with meat practical techniques. Below are some examples:
- Use meaningful names. My code style on academia was, more or less, like this:
What’s count? What’s defcount? What’s delta? It took me a good 5 minutes and a good look at my thesis paper** before making sense out of it. Now, compare it to this one:
It conveys the purpose of the function through function’s and variable’s name, which is counting the difference of number of characters from a text with another text.
- Do one thing. Be it a function or a class, they should not have “and” word when you try describe its responsibility. Not only preventing huge number of lines clumped together, it will also help others (including our future self) to predict what will happen if they use a function or a class. Plus, it will help you to prevent and trace bugs, which equals better weekends.
- Don’t repeat yourself. A common symptom that we’re repeating ourselves over and over is copy-and-pasting code from a class (or function) to another. When there’s a logic that might be used frequently, it would be wise to wrap it to a reusable component – be it a single function, a class, or perhaps, a factory method. The main point is to prevent redundancy, because just like Uncle Bob said, “Duplication may be the root of all evil in software”.
The book covered a lot more topics, such as how to handle errors, writing clean concurrent codes, heuristics to a detect unclean code and how to fix it, and so on. Just like Ridhwan, I would advise you to read the book by yourself! 😉
Why it matters
Now, after all the story about the Clean Code book, let us look about why clean code matters. You might be able to guess what I will tell if you didn’t suddenly jump to this part, but I want to specify the reasons from two point of perspectives – as an engineer, and as a product owner:
- As an engineer, writing clean code will help you to:
- Maintain your code. Be it yourself or other engineers, a clean source code is easier to be maintained, since we should read the code that was already written. So, making the code easier to be read will make it easier to be written, too.
- Fix bugs. Since clean code will make the code easier to read, it will also help you to look for the source of appearing bugs. Plus, it will help preventing another bug pops out because you fixed a bug, since clean codes are well-separated by their responsibilities.
- Add more features. Just like how high-rise buildings built on solid ground, adding more features is easier when it is added on top of code that was bug-free and maintainable. Clean code will help you know what classes or functions that should be added for the new feature, and where should you add it.
- Create payable technical debt. IMHO, technical debt is good, as long we know how to “pay” it later on. There are times that you should compromise not writing clean code to quickly ship a product – e.g. minor tweaks that asked by client just before you send the app to App Store. Even Uncle Bob advises it. When you have a clean code base beforehand, you’ll know how the new “duct-tape code” will affect the whole product. Yet, don’t forget to pay (read: refactor) it later, or it will slowly grow to a nasty rubble.
- As a product owner, having your engineers (or yourself) to write clean code will help you to:
- Build a solid product. Nobody wants to build a bad, full-of-bugs product. As I stated on the engineers’ side, a product built on top of clean code will have less bugs than not. Plus, it’ll help fixing user-reported bugs, since your engineer knows where to look to fix it.
- Deliver a new feature. Still related to the engineers’ side. It would be nice if your engineers spent more time to focus on writing a new feature instead of fixing a bug first before writing a new feature, isn’t it?
- Sell your product. If you got a solid product and killing features, you’ll have more time thinking about how to selling it instead of worrying if it will went wrong on your next pitch! 😉
Phew! Well that’s quite a lot, isn’t it? Hopefully you’ll be eager to start reading Clean Code (or practicing it, if you have done it already). It helped me a great deal throughout my software engineering career. Don’t hesitate to share your thoughts or questions on the comment box below! Plus, I’ll try to post 7 clean code practices that I mostly use next Friday, so stay tuned! 😉
(*) Ridhwan is a prodigy indeed. He was playing around with the first generation of Unity SDK when our class was learning Java. He used it to join a national game development contest with his team and sweep all the jury’s feet! Too bad his team only won the second position, though 😔
(**) Well, the snippet above was a kind of simplified version of my thesis paper’s code. The real one was… worse. Thank God that I read the book at early stage of my career! 😂
