Block structure

Other languages, notably Basic, used the Goto but academic language like Algol took a different approach. Instead of copying they machine code they introduced control statements that gave the programmer the ability to write If statements and loops with not a Goto or a jump to be found.

To many programmers at the time this was either a revelation or a mystery. Languages like Algol were hard to understand for programmers brought up on the free use of the Goto.

Why make things difficult when a simple jump to the code you want to execute next is all it takes?

The answer is of course that the free use of the Goto creates spaghetti and block structure produces a simpler flow of control graph. Notice that you could use the Goto to create simple and neat flow of control graphs but this needed discipline and understanding.

The structured programming revolution

We were heading towards a crisis. The majority of programmers were producing spaghetti and there was a growing need for more and better quality code. Dijkstra then wrote his famous paper about the Goto being a bad thing and people started to think about the problem. The idea was that if you reduced programming to a simple set of building blocks then programmers would have to produce neat and simple flow of control graphs. The era of "de-skilling" had started.

The idea was to make programming so easy that you didn't need spaghetti experts to create programs.  Languages like Algol and Pascal only provided block structured statements the if..else and three loops the for, the while and the until loop. This was all you needed. You could prove that it was all you need - any flow of control graph could  be constructed using just these few constructs. In fact you could prove (to be more accurate Dijkstra proved) that you only needed the if and either the while or the until loop and some extreme theorists proved you only need one of the loops as they gave you a conditional execution facility.

So the Goto was out and structured modular programming was in. You wrote programs that consisted of tiny little bits of code - procedures - and each procedure had a small number of conditionals and loops. They had to be small enough to understand in a single quick look.

Modular structured programming was the only programming method in town and it was enforced  almost brutally. Programmers were dragged kicking and screaming way from the freedom of the Goto and into the straitjacket of structured modular programming. Of course it was for their own good.

The programs that resulted were better. Dijkstra even thought that the free use of the Goto was so bad that exposure to it damaged the mind of a programmer for life. It certainly caused many a programmer to slip in a Goto into an otherwise fully structured program just because it seemed the easy way out.

In reality a velociraptor probably didn't appear and eat them - but the spaghetti monster probably did.

The state of spaghetti

Today most languages use block structure but some have slipped the Goto back into the list of control statements - why I have no idea. You can prove that you never need the Goto and its use is always detrimental to program structure - but it's there if you really need it. It's there as a sort of comfort blanket or perhaps for days when you want to reenact scenes from old programming practices or simply to cook up a bowl of spaghetti code to frighten the beginners.

However the Goto isn't the only bad statement prowling around. Since the early days of structured programming language designers have tended to add structures that they think might make their languages more useful. You can now generally jump out of loops and conditionals and we have loop constructs with exit points anywhere you care to place them. These are very capable of being misused to create spaghetti - but few are warned of the possibility.

Object-oriented programming also has a lot to answer for. Done properly it's great. But the need to write methods that do something coherent in terms of the object mean that methods get bigger and bigger. With structured modular programming if a procedure got bigger than ten lines of code you considered splitting it into two.

In object-oriented code you start to write an Update method and it starts to get big. What do you do split it? Into an Update_first and an Update_second? You could create some private helper methods but these don't really fit with the object-oriented way of doing things. The trouble is that methods don't naturally break down in a hierarchy of procedures that have any real meaning in what the object is or does - they are simply messy internal working. As a result object-oriented programmers don't think size matters. They write big methods with the result that their flow of control graphs are big and messy - not quite spaghetti but well on the way to linguine.

What can you do to keep your code simple and avoid being eaten by a velociraptor?

All you really have to do is never use the Goto and aim for a simple flow of control graph.

• Don't use break or continue unless it really makes your code simpler - compare to the alternatives.
• Certainly never use break n or similar instructions that break out of n levels of nested structure in one jump.
• Don't nest structures more than two deep unless there is some simple pattern - for example, three nested for loops are just about ok
• If a section of flow of control is getting complicated break it down into methods - each method can encapsulate a part of the flow graph and make it look like uncooked spaghetti. .- i.e. straight.
• If you really want to go the whole way then use some sort of complexity metric such as cyclomatic complexity - but usually this isn't necessary and is mostly a way of avoiding actually doing any programming.

The next time you feel like being adventurous with your code - listen for the breath of the velociraptor.

If you would like to be informed about new articles on I Programmer you can either follow us on Twitter, on Facebook , on Digg or you can subscribe to our weekly newsletter.

<ASIN:0138544719>

<ASIN:0201175363>

<ASIN:0387972994>

<ASIN:0201172372>