Pruning your code — Part 1. I like gardening. I remember how good…
By: Frikkie Van Biljon
Tags: Coding, Coding Principle, Programming, Software Development, Clean Code

I like gardening. I remember how good it felt when I planted my first bed. Although I had to wait a full year for the flowers to bloom was it still very rewarding.

You soon become an addict. I quickly started adding more and more plants and eventually my beds were so full it became basically unmaintainable. Up to the point where I couldn’t distinguish between the various plants anymore.

This eventually lead to later seasons to almost having no flowers at all. I needed advise.

My grandmother who is blessed with ten green fingers, was called in to consult.

Her advice that day changed my whole perspective on how to approach my garden.

“The best investment you can make in your garden is to prune away what is not needed.” — Grandma Phia Venter.

That got me thinking. Surely I’ve seen before and after pictures of gardens on the internet and always thought that the key was to redo. But with her words in my head, I realized that you can clear up the mess by removing the overgrowth and by restructuring what you have.

I started searching for images online and found this garden.

Soon I would apply this advice to my own garden and took out all my plants, cut away 2 thirds of it, replanted the same plants and waited for a year to pass.

The results were astounding.

Restructuring

1 Year Later

My same flowers and plants, suddenly had new life.

What happened?

Pruning encouraged my plants to bush which resulted in more flowers being produced.

Maintaining my garden is now easier — spotting dead leafs for example is easier.

Improved the overall aesthetics of my garden.

Shaping of my plants improved.

Layout and vision of my garden is now clear and easier to understand.

This got me thinking.

How does pruning relate to software development?

I came to realize that the following is true for software development:

We forget to “prune” our code.

We are allowing our code to branch freely.

We need to remove unnecessary branching.

Maintenance is becoming more and more complex over time.

Layout and design becomes unclear.

But why is this happening?

Where did GoTo go to?

GoTo is a statement that allows for the one-way transfer of control to another line of code. Unlike a functional call that will return the control. The jump-to locations are usually some form of label or line number.

This can be considered branching. By implementing a GoTo statement you have created a new path of execution for your code.

Why is this bad?

Using GoTo can lead to programs that are extremely difficult to comprehend and analyze. This can lead to unspecified behavior and increase the rigidity of your code.

Many programmers today will argue that we are not using GoTo statements today since a lot of programming languages doesn’t support it anymore so why even speak about it?

Let’s consider the following snippet of code. Try and find the GoTo statement:

private boolean processTransaction(Transaction trans) {

// do some session security checking

User user = trans.user;

log("security check for user " + user.name); if ( user.loggedIn() == false)

return false; if ( user.sessionTimeout() == true )

return false; boolean success = true; // process transaction here

return success; }

Conditional statements, IF and SWITCH should be considered as GoTo statements.

IF condition THEN goto SWITCH expression CASE goto

We are over utilizing conditional statements.

Why is branching bad?

Branching is expensive on the CPU.

When the processor sees a branch instruction appear in its pipeline, it needs to figure out how to continue to fill up its pipeline.

In order to figure out what instructions come after the branch in the program stream, it needs to know two things:

if the branch will be taken and

the target of the branch.

Figuring this out is called branch prediction, and it’s a challenging problem. If the processor guesses correctly, the program continues at full speed. If instead the processor guesses incorrectly, it just spent some time computing the wrong thing.

It now has to flush its pipeline and reload it with instructions from the correct execution path.

Bottom line: a big performance hit.

Branching can lead to the arrow-anti pattern.

Nested conditional statements can be very hard to debug and maintain.

How do I prune my code?

In the next part we will take a look at how you can prune your code by removing most of the conditional statements. We will investigate alternative ways of writing functions to be cleaner, shorter and IF-less.

Changing old habits are hard. Especially if you started loving them. Solving problems by using conditionals became second nature to us. Like Dijkstra said:

The prisoner falls in love with his chains.

We will rework some code by removing IF- and SWITCH-statements and consider if pruning our code yields better fruit.