A New Didactic Approach to Teach Beginners About Code Complexity

From 2011 till 2017, I taught Java to beginners during my time at the Distributed Systems Group in Bamberg, Germany. It was an awesome experience, helping those young programmers on their journey to become professional developers. I learnt a ton about programming myself and how to teach someone to program and code better — and co-wrote a paper and a book from that experience. Today, I want to talk about another idea on how to help beginners write better code that’s spooking around in my mind: Pay for Complex Code with Screen Estate, although I am still working on that term… The general didactic concept is as follows.

The more complex the code is, the more screen estate you have to pay.

Sounds strange? Let me give you an example. According to Reading Beside the Lines: Indentation as a Proxy for Complexity Metric the more indentations code has, the more complex it is. Normally, we use (read: pay) 4 spaces per indent. The more complex our code is, the more of those “4 spaces indents” we have. By paying, for instance, 8 spaces per indent, complex code becomes much more expensive in terms of screen estate. Or even 16 spaces per indent. Or, the other way round, with 2 spaces per indent (which seems to be a common option nowadays as its so compact) we pay very little screen estate for complex code. Overall, we use the following formula to calculate the amount of spaces:

indents * indent_length

Here’s the code of two different FizzBuzz implementations, both using 4 spaces as indentation. The first one uses a lot of indents whereas the second one doesn’t. Have a look at the code and think about whether the visuals of the code really hints at whether it’s easy to maintain and understand.

https://medium.com/media/b62ccf0b340664617ef8880050aa159d/href

In the code above, we pay the same for every single indent. Instead, I’d like that the more one indents the more one has to pay so that a beginner immediately gets the increasing costs of the next indent. So I suggest the following:

The amount of spaces increases per indent.

Let me give you an example to make this more clear. We use 2 spaces as the initial indentation and 1 space for the increase. The first indent has no increase and is simply the initial indentation of 2 spaces. The second one would be 2 spaces plus 2 + 1 spaces, resulting in a total of 5 spaces. The third one would be 5 spaces plus 2 + 2 spaces, resulting in a total of 9 spaces. The fourth one be 9 spaces plus 2 + 3 spaces, resulting in a total of 14 spaces. You can also use the formula:

indents * indent_length + sum(indents-1) * increase_length

Let me show you that in the following code. I reused the code from above that already uses an indent with 4 spaces and just added an increase by 4 spaces. Have a look.

https://medium.com/media/7ddcba8859a520a4583343759b8afe41/href

One can immediately see the change. But even the less complex version looks bad although it’s actually quite clean. What’s wrong? In Java, we need to put our code in classes that have methods. A line in a method already requires two indents. And when we use an if condition, a for loop or a try-catch construct, we already have three indents. We need to take those into account as well and refine the previous statement to the following:

The amount of spaces increases per indent, ignoring the first three indents.

This requires a change in our formula:

indents * indent_length + sum(indents-ignore_indents) * increase_length

I formatted the FizzBuzz implementations again, but now applying the increase starting with the fourth indent instead of the first one. Have a look at the improved version below.

https://medium.com/media/de75ac78a7da572e8da5b42f1825fad4/href

The less complex version is exactly the same as the original one with the “standard indentation” we are accustomed to, but the complex version clearly signals the complexity through its modified indentation.

This is a didactic concept and should not be used in production code. It’s an approach to help beginners get the concept that code indentation signals code complexity and discuss with them how to overcome that complexity through refactorings, such as extract method that encapsulates code and gives that code block a name (i.e., the method name). It’s also not something that should be enforced all of the time in an editor. Instead, I recommend to apply that formatting live in class and then discuss with the students the issues of high cognitive load.

In summary, this approach might help beginners understand more quickly why it’s better to write code without resorting to a lot of indentations. It’s just a first step towards the idea of paying for complexity directly within your code editor. Another idea is to add whitespace within complex expressions, increase line spacing the longer a method becomes, and change the font size in relation to the length of a variable name.

Postscript

This approach can’t work in Python because this language requires a certain indentation scheme that’s contrary to the idea in this article.

I’ve written the code to generate those formats in Ruby. Because it contains a lot of indentation, it’s not well suited to be placed here. If you still want that code, feel free to contact me directly.

I use spaces throughout this article to indent code and not tabs. I don’t want to restart the war on tabs vs. spaces here. I simply use spaces and that’s why I use spaces it in the article. This approach works with tabs, too.