#begin

Today we are going to continue with the next chapter of the Clean Code book by Uncle Bob. So this next chapter is a short one, it’s only 5 pages long and it’s about Emergence, whatever that means right? The chapter starts of with a section called: Getting clean via emergent design and he asks the question what if there were rules you could follow that help you create good software. This is a rethorical question of course because Uncle Bob immediately refers to the four rules of simple design created by Kent Beck. Let’s check them out!

Emergence

So these four rules of simple design go as follows and are given in order of importance; A design is simple if:

Rule 1: It runs all tests.

We’ve discussed this to great length in the previous episode. When your code runs a shit ton of tests, you can really easily change or extend it and just re-run the tests. This is very simple.

Rule 2: It contains no duplication.

Duplicated code is a horrible code smell that should be dealt with. However, there are nuances. Some code that looks duplicated, does many of the same things, sometimes is not duplicated code since it belongs to other use cases or other domains even. You should not abstract this out to remove the duplicated parts. But we’ll talk more about this a bit later, let’s discuss the rules first.

Rule 3: It expresses the intent of the programmer.

Well this is what this entire book is about; we write clean code so we can more easily express ourselves in code. And not have to write these horrible comments everywhere for example.

Rule 4: It Maximizes the number of classes and methods.

This one feels contradictory right? I mean maximizes the number of classes and methods. This feels like a competition. But we talked about some of the SOLID principles already and the SRP, the single responsibility principle emphasizes that you should keep classes small and cohesive. And this is what rules 4 means basically.

But let’s dive a bit deeper into these rules now.

So rule 1 was, a design is simple if it runs all tests. And as I said, if you have a system covered in tests you can really easily change it since you just do, and run all tests again. If they pass, your change is correct, if not, ctrl+z long enough to reach the initial state again. It’s that simple; but we also talked about the nuances of Tests in a Unity3D system. In Unity3D you simply cannot meaningfully cover every single thing with tests. Some things are just to coupled with Unity, and separating them will lead to inexpressive code and might even result in performance penalties. But I do agree with Uncle bob that, having lot’s of tests gives you more trust in the code and trust that you can easily change it. He says that a system might be perfectly designed on paper but there is no way to verify that design, that is actually works, until you write it.

Rule 2 was about a design being simple when it contains no duplication. And this is a tricky one since some people will tell you that duplicated code must always be removed, abstracted and reused. But in some cases, there’s code that is written the same, looks the same, does the same but is in fact different because they belong to different domains. This is very important to understand and I’ll give you an example. In a system I’m currently building are a couple of objects that can get a “deprecated” state if a content editor decides to deprecate them. So certain objects can be put in this state, however, how the system should respond to these deprecated objects is different in all cases depending on the type of object, and it has not been decided yet what this behaviour aught to be. So I could make some base-classes for the use-case objects for each of these classes. But at this point in time, it makes no sense to me to do that since I’m 90% sure that the usecases to deal with these deprecated objects is separate from each other. So although they seem related, they will result in far different behaviours. So what I’m trying to say is, not all duplicated code, is actual duplicated code. And if you always generalize all duplicated code, you’ll notice that you will always depend on some core module or library. Which is OK, ofc but don’t just refactor all duplication from your code base for the sake of removing duplication since there are nuances with this. Not all duplicated code is an actual duplicate. I’m not sure how to identify this quickly, but I think this comes with experience.

Let’s continue with rule 3, a design is simple when it expresses the intent of the programmer. Well I think if you have read to the past entries of this series you know what is meant by this rule. It means that the code is clean and readable. And you know by simply reading the code, what the code does. It’s not obscure, cryptic and it’s not a big bowl of spaghetti. You use lot’s of small functions to create decoupled and cohesive coder and make sure everything is named according to what fits the domain and known design patterns. It’s what this book is about and what we have talked about for the past 11 blogs I guess. So let’s continue with rule 4.

Rule 4 states that; a design is simple when it maximizes classes and methods. This might feel contradictory right? I mean maximizes classes and methods, that sounds like you should create classes and methods for everything you see, and that might lead to one big confusing cesspool of randomly named classes. But what is meant by this rule is that you should program with the single responsibility principle in mind and thus do not make classes that answer to two stakeholders. These classes should be small and cohesive and avoid the problems of duplication.

So that’s it already for this chapter. As I said it was a short one. A key take away from this chapter is that you should keep your code simple. We discussed the four rules created by Kent Beck which sound easy but in practice they will sometimes be difficult to adhere to. But it’s in everyone’s best interest that you follow them. And yes, that also means that manager who is breathing down your neck to get things “finished” on time. It’s in his best interest that you write simple code, create tests for it, does not contain duplication. He might think it’s unimportant in the short term, bit in the long run he will reap the benefits as well. Remember that.

Thanks for reading and remember these four simple rules!

#end

01010010 01110101 01100010 01100101 01101110.