#begin

Alrighty! In the previous blog we got up to chapter 13 of the clean code book. Chapter 13 is the last chapter of the book I can meaningfully cover in a blog format. The remaining chapters are all case studies with a lot of code and examples. Uncle bob shows you how to apply the practices you learned in the book, and by this blog of course. These things are just not easily explained with just audio and thus the in-depth coverage ends at chapter 13.

But if you are interested in these remaining chapters please, get the book and dive into it. Also, the previous blogs covered each chapter so if you want to read along you can also do that. It’s not a true like audio book since I gave the content in the book my own spin and tried to relate it to a unity3d context where it made sense. I’ve tried to come up with some tangible examples to explain many of the concepts.

And in this blog I’m going to wrap things up but diving into alternatives to clean code. I know that not everyone agrees with Uncle Bob, as a matter of fact I think many people do not agree with Uncle Bob because he’s very prescriptive. He can sometimes tell you in a pretty harsh way that you should do things his way or else you are not a “professional”. So I can understand that some people don’t like that. But because of that you should not ignore the advise he can give you.

But still, there’s a lot of push-back on the clean code book and Uncle Bob. You may know someone who really dislikes the practices in the book. Or maybe you are that person. So to also speak to you and all these others that dislike clean code practices I promised to create some extra blogs where I dove into the alternatives to clean code. So, for this blog we are going start to look into three of them. There’s probably more but these are the ones that are recommended often and I have read myself over he past couple of years.

We are going to cover “the pragmatic programmer” by Andy Hunt and Dave Thomas, “A Philosophy of Software Design” by John R. Ousterhout and “Code complete” by steve mcconel. And I’ve read all three of these books and I think they are reasonable alternatives or even a way to further augment clean code.

So In this blog we are going to discuss the first two chapters of A Philosophy of Software Design by John R. Ousterhout and it’s an amazing book. There are some real gems in here you should keep in your mind when designing game systems and logic and software in general.

A Philosophy of Software Design

So let’s start with A Philosophy of Software Design by John K. Ousterhout. He’s a professor at Stanford University and he himself wrote this book based on a software design course he teaches there. This book is sort of a companion for the course and it’s a rather short one compared to other Computer Science book, but that’s nice. When I was in University one of my professors said that it was a real art to write things down with as less words as you can but still provide enough information to explain the concepts you are writing about. So a short book is not necessarily a bad thing. And in this case, I can promise you, it’s not a bad thing. This is a really great book, so let’s have a look at it and discuss it as an alternative to clean code. There are some contradicting advise in here so let’s find out what they are.

So let’s quickly describe the Preface of the book, in here John makes the case that “the most fundamental problem n computer science is problem decomposition; How to take a complex problem and divide it into pieces that can be solved independently.” He also says that many classes about programming are about writing code, writing loops and object oriented programming, but not about design. But this is where I disagree, because well it depends. The bachelor I did was mostly focused on software design, lot’s of requirements engineering, UML, architecture and design patterns. So I think it depends on what course you do at what institution. But I might agree with him that in most of the cases, design is not thought properly.

But OK, he wrote this book as a companion for the course he designed himself; CS 190 at Stanford which he had given three times at the time of writing the book. He also notes that the book touches on topics that are rather high level or philosophical so it’s a good idea to do some actual coding and try to apply these principles because most student have a hard time learning abstract concepts. When you code, you can apply things in concrete matters and you need to think things through.

There is also a nice concept in this book which he calls the red-flags of software design. These are little highlights in the book that provide truly valuable information. And he said in on of his talks you can find on youtube, which I’ll put into the shownotes that. If you remember anything of this book, please remember the information in the red flag snippets.

So the first chapter in the book that provides us with some information is chapter 2, The nature of complexity and he defines complexity as: “Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system”. That’s a pretty clear statement I think, but it’s also rather subjective. But luckily he wrote down some symptoms of complexity as well. First there is change amplification which says that a seemingly simple change requires changes in many places. Haha, right. If you have programmed for over 3 weeks, you have probably ran into this issue. Next there is Cognitive load which refers to everything a developer needs to know in order to complete his task. So the higher the load, the more time you must invest to read, learn and understand the code. And last, there are the unknown unknowns which is that it is not clear which pieces of code must be modified to complete a task. I bet you will run into this problem when you start coding on some existing project that might be poorly designed.

And he says that complexity is often caused by two things: dependencies and obscurity. And he defines a dependency as “when a given piece of code cannot be understood and modified in isolation; the code relates in some way to other code”. This is an interesting contrast to practices in Clean Code right? I mean in clean code we are encouraged to abstract as much as we can and thus this might impact understandability on both sides of the spectrum, depending how you look at it of course. If you abstract things out, you might need to read some other classes as well which might increase your perception of complexity because you cannot change it in isolation. But on the other end, if it’s abstracted out, you do not have to read that code to change they things you are about to change. So it depends on how you look at this. An yes, if there are concrete dependencies everywhere, then this point is perfectly valid, but if the dependencies are hidden away behind polymorphic interfaces then it will most likely reduce complexity.

The second cause of complexity was obscurity which occurs when important information is not obvious. The example he gives are bad variables names that do not provide enough information to act upon. Like a variable called “time”. What do we know now?

The last thing he states in this chapter is that complexity is incremental which is certainly true. I mean, how many of you have started a greenfield project and moves very very quickly in the beginning but start to slow down after a couple of sprints. And a sprint refers to Agile or SCRUM terminology. Agile is a software development methodology where you work in short iterations called sprints. So you should always do your absolute best to manage complexity in all the work you do because it can creep up on you.

So I hope you enjoyed reading this as much as I did, It’s been quite a while ago since I last read this book so it was really nice to refresh some of the concepts that are in it. In the next blog we will take a look at chapter three.

#end

01010010 01110101 01100010 01100101 01101110.