Programming

Code Complete 2 – Steve McConnell – Unusual Control Structures

I just love Steve McConnell’s classic book Code Complete 2, and I recommend it to everyone in the Software ‘world’ who’s willing to progress and sharpen his skills.

Other blog posts in this series:

Recursion

For a small group of problems, recursion can produce simple, elegant solutions. For a slightly larger group of problems, it can produce simple, elegant, hard-to-understand solutions. ?

Java Example:

void QuickSort( int firstIndex, int lastIndex, String [] names ) {
    if ( lastIndex > firstIndex ) {
        int midPoint =  Partition( firstIndex, lastIndex, names );
        QuickSort( firstIndex, midPoint-1, names );
        QuickSort( midPoint+1, lastIndex, names );            
    }
}

In this case, the sorting algorithm chops an array in two and then calls itself to sort each half of the array. When it calls itself with a subarray that’s too small to sort-such as ( lastIndex <= firstIndex ) – it stops calling itself.

Tips for Using Recursion

  • Make sure the recursion stops – Check the routine to make sure that it includes a nonrecursive path.
  • Limit recursion to one routine – Cyclic recursion (A calls B calls C calls A) is dangerous because it’s hard to detect.
  • Keep an eye on the stack – With recursion, you have no guarantees about how much stack space your program uses. To prevent stack overflow, you can use safety counter and set the limit low enough or allocate objects on the heap using new.
  • Don’t use recursion for factorials or Fibonacci numbers – You should consider alternatives to recursion before using it. You can do anything with stacks and iteration that you can do with recursion. Sometimes one approach works better, sometimes the other does. Consider both before you choose either one.

goto

You might think the debate related to gotos is extinct, but a quick trip through modern source-code repositories like SourceForge.net shows that the goto is still alive and well and living deep in your company’s server.

The Argument Against gotos

The general argument against gotos is that code without them is higher-quality code
+ Dijkstra observed that the quality of the code was inversely proportional to the number of gotos the programmer used
+ Code containing gotos is hard to format
+ Use of gotos defeats compiler optimizations
+ The use of gotos leads to the violation of the principle that code should flow strictly from top to bottom

The Arguments for gotos

The argument for the goto is characterized by advocacy of its careful use in specific circumstances rather than its indiscriminate use.

A well-placed goto can eliminate the need for duplicate code. Duplicate code leads to problems if the two sets of code are modified differently. Duplicate code increases the size of the source and executable files. The bad effects of the goto are outweighed in such a case by the risks of duplicate code.

Good programming doesn’t mean eliminating gotos. Methodical decomposition, refinement, and selection of control structures automatically lead to goto-free programs in most cases. Achieving goto-less code is not the aim but the outcome, and putting the focus on avoiding gotos isn’t helpful.

Summary of Guidelines for Using gotos

Use of gotos is a matter of religion. My dogma is that in modern languages, you can easily replace nine out of ten gotos with equivalent sequential constructs.

  • Use gotos to emulate structured control constructs in languages that don’t support them directly. When you do, emulate them exactly. Don’t abuse the extra flexibility the goto gives you.
  • If goto improve efficiency, document the efficiency improvement so that goto-less evangelists won’t remove it.
  • Limit yourself to one goto label per routine
  • Limit yourself to gotos that go forward, not backward
  • Make sure all gotos labels are used.
  • Make sure a goto doesn’t create unreachable code.

Written by Nikola Brežnjak