Transcript Does it even start? What are you looping?

Software Engineering


Loops
Unusual control structures
Loops

Kinds of loops:




Counted loop – to be performed a specific
number of times.
Continuously evaluated loop – to be
performed till a certain condition erupts.
Endless loop – to be performed forever.
Iterator loop – to be performed once for each
element in a container class.
Loops

Controlling the loop:

Entering the loop:




Put initialisation code directly before the loop.
Infinite loops – use a standardised construct,
e.g. while (true) or for ( ; ; ).
In general, prefer for loops when they are
appropriate – for loops package the loopcontrol code in a single place.
Do not over-use for loops – especially, do not
add code to the for conditions that is not
control code.
Loops

Controlling the loop:

Processing the middle of the loop:




Use brackets every time, even if they are not
strictly necessary.
Avoid empty loops, e.g. those in which all the
work is done in the condition testing code.
Perform loop-housekeeping (e.g. i = i+1 or
j++) either at the beginning or at the end of
the loop.
Unless strictly necessary (e.g. for efficiency
reasons) make each loop perform only one
function.
Loops

Controlling the loop:

Exiting the loop:





Assure yourself that the loop really ends.
Make loop-termination conditions obvious,
e.g. by putting the control in a single place.
Do not manipulate the loop index to force
loop termination.
Avoid code that depends on the loop index's
final value outside the loop.
Consider using safety counters, i.e. additional
counters to control how many times a loop is
executed.
Loops

Controlling the loop:

Exiting the loop – safety counter:
safetyCounter = 0;
do {
(...)
safetyCounter++;
if (safetyCounter >= SAFETY_LIMIT) {
Assert(false, “Safety counter violation”);
}
} while (<do condition>);
Loops

Loop variables:




Use ordinal or enumerated types for
limits on arrays and loops.
Use meaningful variable names to make
nested loops readable. Avoid i, j, k, ...
Be careful with loop indices cross-talk.
Limit the scope of loop index variables to
the loop itself.
Loops

Loop length:




Make your loops short enough to view all
at once.
Limit nesting to three levels.
Consider moving portions of a long loop
to routines.
Make long loops especially clear.
Unusual control structures

Multiple return's from a single routine:


Use a return when it enhances
readability.
Use guard clauses (e.g. early return's) to
simplify complex error processing:
if Test1 {
if Test2 {
if Test3 {
(...)
}
}
}
if ! Test1 { return; }
if ! Test2 { return; }
if ! Test3 { return; }
(...)
Unusual control structures

Recursion:




Make sure the recursion stops.
Consider safety counters to prevent
infinite recursion.
Limit recursion to one routine – avoid
cyclic recursive paths through several
routines.
Keep an eye on the stack.
Unusual control structures

Recursion:

Consider whether you really need
recursion:


Do not use recursion for trivial routines, like
factorial or Fibonacci numbers.
Consider using iteration and explicit
management of stacks, and balance
advantages and disadvantages of each
solution.
Unusual control structures

Goto's:

Avoid using them. If you really want to
use them, then





Are goto's used only as last resort, and then
only to make code more readable and easier
to maintain?
If a goto is used for matters of efficiency, has
the gain in efficiency been measured and
documented?
Are goto's limited to one label per routine?
Do all goto's go forward, never backward?
Are all goto's labels used?