#begin

Finally! Writing a new blog and in this case a book review. This time it is about Clean Code by Uncle Bob Martin. This book has made a big impact on many people, me included. The book gets recommended a lot to many developers ranged from juniors to seniors and generally it lands very well. But there’s also many people who think that the content in the book is dated and far to prescriptive. And I guess, they might be right but that does not mean it is worthless or you can modernize the disciplines in the book a little bit yourself.

I have been thinking to do a review of this book for some time now and I got triggered to write it since I want to revisit it quickly before I make a podcast about how to apply Clean Code in a Unity3D context.

For this blog I’m going to try and write a more organic kind of review. I’ve done a couple of reviews where I basically list all the chapters and give my opinions about it. I’m gonna try a different way this time a round. I’m gonna make it a series blog where I can dive a bit deeper into each chapter and add some tips and tricks to apply things in C# and Unity3D. Let’s get started.

Clean Code!?

So first of all, what the hell is clean code and what would make code dirty, or bad? Well, for the book, Uncle Bob asked some of his peers about what they thought clean code was. So he asked Bjarne Stroustrup, Inventor of C++, Graady Booch author of some very good software design books, Dave Thomas Founder of Oti, Micheal Feathers and Ron Jeffries, both authors and Ward Cunningham who is the inventor of Wiki’s, Fit, coinventor of eXtreme programming, and a force behind design patterns and SmallTalk and much more.

They all gave their opinion about what exactly clean code meant to them. And personally I like the explanations given by Micheal Feathers and Ward CunningHam the most. Micheal feathers says that “Clean code always looks like it was written by someone who cares” and Ward CunningHam says that “You know you are working on clean code when each routine your read turns out to be pretty much what you expected”. Note that they talk about how it looks and reads and not about how functionally awesome it is.

For example; we probably all know someone who likes to write really clever algorithms that look cool on paper and make use of some cool compiler optimizations and stuff, but a very unreadable. You can probably find a couple on StackOverflow right now.

So that being said, Clean code is mostly about readability and maintainability but of course, as with any code it must be structurally correct, compiling if required of course and working.

Dirty code?

So then, what about dirty or bad code? Well, I think, we all know what bad code looks like, even without knowing what clean code aught to look like. I bet, we can all think of some part in the code you do not dare to change because if you do, you will probably break it. And the thing is, we are programmers, we write code… so by being afraid to edit some code makes you unable to do your job. And, well, that’s very unprofessional!

Imagine some car mechanic telling you he can’t fix or upgrade your car because he’s too afraid he’s gonna break something he did earlier. You would probably tell the guy he’s an idiot and go look for another mechanic who can do it. Well, the same goes for software. There will always be code so we must take great care of it and not let it rot because it will slow us down and hinder development and in the end, the business.

And no, doing a redesign of the entire project at some later point in time in an effort to fix things is unacceptable. Imagine telling the business, after years of developing some software that the only solution to fix all the bugs and frequency at which new features are released is to throw it all away and start over. This is the worst news any manager or CIO can get. Well, maybe Log4J was bad as well but you know what I mean. Also, when you do a redesign of a system that is already in production, you need to maintain two projects. The old one, where you do bugfixes and of course add new features because your users want them. And, the new project, trying to keep up and anticipating the new features to try and fit them within some new design. In the end, you will end up with the same mess!

So, we as developers must take responsibility to write, good, clean code. We must make sure we maintain the code, not just our own but also that of your colleagues. Because why would we? Well we as programmers spend more time reading code, than writing it. And thus, code must be readable. If it’s not readable you don’t know what it’s doing and thus cannot possibly make the changes you need. What do you do in this case? Of course, attach a debugger and run through it. Or Worse, add many Debug.Log() statements in the code to try and figure out what to do.

No you wouldn’t do both of these things. What you would to of course, is run the tests for this piece of code. If there are any of course. And I know it’s very rare to find Unity3D projects that have proper tests! And yes, if there aren’t any tests, go write some yourself if the code is decoupled enough to be testable. Or maybe, ask the developer who wrote the code to explain it to you, if he or she is available to you.

Uncle bob has a rule or discipline that tries to mitigate the code worsening or rotting over time. He calls it the Boy Scout rule which says that you must: “leave the campground cleaner than you found it”. What this essentially means is that you should always check the code in, cleaner than you checked it out, like in Git. So even if you just have to add 1 line of code, refactor some of the code around it to make it cleaner to fit the most recent design, coding standards or other kinds of policies. If everyone would do this, the code would not worsen over time as we sadly commonly still see, it would get better with time. Which would be really great, wouldn’t it?

So the importance of clean code is important to every stakeholder of a software project. May that be direct or indirect. We as developers must take responsibility to make sure the code is as clean as it gets. But how exactly can we do that, how do we write clean code, what practices and disciplines can we use to guarantee that? Well, that is exactly what this book is about! We will explore this topic in grave detail.

So then, what topics does the book address?

1. Meaningful names, what do you call things?
2. Functions, what makes a good function?
3. Comments, why should we write them? Or don’t we?
4. Code formatting and layout
5. Objects and data structures, inheritance over composition? Or not?
6. Error handling, how do we properly handle fault situations
7. Boundaries, how to deal with 3th party code. It has a chapter dedicated to “Learning Log4j” hahaha. I never noticed that haha
8. Unit tests and TDD, I’m not quite sure if we cover that in this …..
9. Classes and proper encapsulation and size
10. Systems design
11. Emergent design based on TDD, not sure if we cover this because it feels it’s a different ….
12. Concurrency disciplines, which are very important in a Unity context as well

So that’s it for the first part of this blog. The upcoming blogs will focus on the chapters individually. I’ll try to cover most of the practices and advice that’s presented in the book but I might skip the Topic of TDD since I think that might be an entire blog series of it’s own. I’m not sure yet though so I might still add it, we’ll see.

Thanks for reading, and see you next time! 

#end

01010010 01110101 01100010 01100101 01101110.