In the early days of programming, the first high-level languages very much followed the pattern of assembly language. Control was transferred around the program with a GOTO statement. For simple applications, written with some care, this was acceptable. But when a program reached any level of complexity, another approach was necessary. So, languages like Fortran and BASIC were followed by PL/1 and Algol, which led directly to the languages commonly used today, like C.

The main improvement in procedural programming (as opposed to object-oriented programming, which is another beast entirely) was the concept of a “block”. A block is a chunk of code – a number of statements – that can be treated as an entity. For example, an IF statement can determine whether a block of code is executed or not instead of controlling a jump (GOTO) around it. The result is more readable and, hence, maintainable code.

The C language does have a goto statement, but it is generally agreed that it should only be used in extreme circumstances. There is also the break statement. Some developers are a little confused about its functionality, but it is really quite simple. The definition from Microsoft is succinct: The break statement terminates the execution of the nearest enclosing do, for, switch, or while statement in which it appears. Control passes to the statement that follows the terminated statement.

The use of the break statement is somewhat controversial, as it can be seen as contrary to the ethos of structured programming. However, its use in a switch statement is totally acceptable:

switch (ss)

{

case 1:

   alpha();

   break;

case 5:

   beta();

   break;

case 11:

   gamma();

   break;

default:

   panic();

   break;

};

It provides a neat end to each clause and is considerably clearer than allowing the code to flow from one clause to another, which is forbidden by most programming standards. The break in the default clause is, strictly speaking, redundant, but it maintains clarity and maintainability with no extra code being generated.

The controversy about the use of break comes when it is used to prematurely exit a loop. However, its careful use normally results in clear code. A loop may be coded like this:

for (i=0; i<100; i++)

{

   retcode = myfunction();

   if (retcode == -1)

      break;

}

The alternative, avoiding the use of break, might look like this:

for (i=0, exitflag=FALSE; i<100 && !exit_flag; i++)

{

   retcode = myfunction();

   if (retcode == -1)

      exitflag=TRUE;

}

This is considerably less readable and may result in the definition of an unnecessary variable (but a good compiler might actually optimize it away and result in the same code).

As developers spend more time debugging than coding and even more time maintaining code, readability should always be a very high priority and careful use of break makes a positive contribution.