Clean Code - Review

I have recently finished reading this masterpiece of a book. I started reading it while working on a group programming project for uni and, at that point, I wasn't aware how useful it would turn out to be.

This book has a quite suggestive title. It teaches you methods, heuristics and different techniques to envision, structure and, ultimately, write cleaner code. It does that by both explaining and showing examples. It gives you refactoring tips, code architecture tricks and more.

I have heard of this book before. First thing that came to my mind was "why would I waste my time to read such a big book just to write clean code?" and "why would I bother?". Us, young programmers, usually go by the rule of "if it looks stupid but it works it's not stupid". And yes, we find ways to make our code function as it's supposed to, but the methods that we use sometimes leave long lines of clutter and undecipherable gibberish. If you are one of those programmers who relates to the feeling of not wanting to look back to your code after you have made something "work", you are in need of an attitude adjustment. And please don't feel attacked by my earlier comment, since this train of thought was no stranger to me.

Why would you feel scared of going back to your earlier work? You did a great job, didn't you? You passed all the test cases that you envisioned. Now, you want to add new functionality to your program, but this means that you'll have to "figure out what you did there" again. This was my greatest block and it is still a great block for a lot of my colleagues at uni. We are trying to finish the work, and to finish it fast. This means that we are efficient, right? Well, it's the worst mindset a programmer could have.

I have learnt from this book that there have been cases (not many that I have heard of, but at least a couple) when bad code meant the death of an entire program. Companies have set the coders some deadlines to be met, which forced them to write fast to build the program. They have met that deadline and the main functionality of the program was working fine. Then came the update patches. And feature adding. Again, with fixed deadlines. This time, the deadlines couldn't be met anymore. Any deadline. The clutter became too much and the programmers were stuck. There was no time to refactor anymore, and no funding to rewrite the whole system, so the program had to be discarded. I don't know anything about how the company coped with the loss of the program, but I assure you, nobody was happy.

Why did that happen? Hint? Fast code. As anything that is fast in this life (looking at you, food), it is convenient at that time, but in the long run, and with no break from it, they are followed by great repercussions. Their whole project could have been saved by a couple of refactoring breaks, which they weren't allowed. Names don't come up perfect on the first try, code needs to be reused and repurposed, solutions need to be generalised, functions need to be shortened and made more readable. If these things are good advice when working on your own (when people think that they understand their own code, so they don't need to make it too self explanatory), they are absolutely necessary when working in a team. Programmers are people, and as all people, they need breaks to reflect upon their work and decisions. Well, they weren't given that time, so the code became more and more cluttered, people working on different areas of the code had to look and understand code written by different people and, instead of coding, people had to explain their own code to everyone (and sometimes, they had to remind themselves why they did something in the way that they did). At some point, the clutter became unmanageable, so the production stalled and, at some point, terminated indefinitely.

These issues were extremely relatable for me, as a novice coder. So, I stopped living with broken windows, with code I wasn't proud to look back at to, and started fixing it. A good rule I learnt from this book is the "Boy scout rule": leave the campsite cleaner than when you found it. I had this project going on. In my spare time, I was refactoring my own sections, reworking the architecture of the system if needed be, renamed, repurposed, cleaned up clutter. My point was to make all comments unnecessary. And I did, mostly. I have written code I am happy to show to the world, with great naming conventions and organised formatting and overall structure. If you wish to take a look at my project, check my repo on gitlab: https://gitlab.doc.ic.ac.uk/lab1819_summer/arm11_41. The part I am most proud of is the emulator, check the readme file for more information. Feel free to critique and message me about any ways I could improve the code.

All in all, Clean Code by Robert C. Martin is an amazing book, and I believe any programmer, no matter the experience, can learn a great deal from it. Sometimes I wished my teammates would have read it before working on our project, but I made sure to let them know of the most important tips that I have learnt from it, so they could apply them. I can't recommend this book highly enough. It truly changed the way I look at code, not only mine but also others'. I want to be proud of the code I write, not only in its functionality, but also in its readability. I want to show my code to programmers and non-programmers alike, and I want them to understand my code without me needing to explain it. These are tough peaks to climb on, but they keep me going. If you have this mentality, then this book is right for you.