Skip to main content

#6. Ensure entry and exit conditions in loops

There are at least two questions you should always ask yourself while you're writing code for a loop - and ask yourself again after writing it. Here they are:
  1. Will the loop body be entered at least once?
  2. Will the loop ever be exited?
If your loop is a do .. while, the first question has an obvious answer: yes. It will be entered at least once (as long as the execution point reaches it, of course). That's why you chose that structure in the first place. If it is a while or a for, you should pay more attention to that. Review the loop condition thoroughly and think about the possibility of it being false at the very beginning of the loop. In that case, the loop body would not be executed. Is that scenario correct your design, or is it something to avoid? If the latter is true, then you should write the specific code to handle that.

About the second question, the loop will be exited whenever its condition is evaluated to false. The condition is evaluated once for each iteration. Will it eventually become false? Are you totally sure that this will happen? Can you guarantee it?

If you have other sources of loop exit, such as a break instruction or a return, clearly you are planning different possible exit paths for your loop. Once they happen, will you be able to tell one from another? Is the result of your loop correct for both when the condition becomes false and for the alternative exit paths? Are all the related variables left with the correct values in all cases? Review and test your code to verify that is the case.

There are several sources of infinite loops that you should strive to avoid. Consider this example:

for (unsigned char c = 0 ; c < 256; ++c) {
    std::cout << c;
}

The range of the type unsigned char is from 0 to 255. In C++ addition, unsigned integer types wrap around when they exceed their upper numeric limit, so if the value of c is 255, ++c "increments" it to 0. From there it will go up again, if you keep incrementing it, until it reaches 255, from where it will wrap around again to 0, resulting in an infinite loop.

This behaviour of the C++ arithmetic is neither "right" or "wrong" - it's just how the language is specified. You, as a programmer, must be aware of it and write your code so that it does the right things.

Always keep in mind the numeric limits of the types you use. The comparison c < 256 above violates the guideline against implicit type conversions (see Guideline #2), because 256 is obviously not a value of type unsigned char. It will probably cause a compiler warning, such as "Constant out of range in comparison" (and you should fix all compiler warnings), but anyway, you should be aware of the semantics of the types you use in the first place, including their limits. By the way, you should never use magic numbers such as the 256 above.

You will avoid another source of infinite loops if you follow Guideline #5 and avoid playing with the value of the loop counter inside the loop body. Do not modify the loop counter in the loop body, and it will eventually reach the limit value of the loop condition so that it can become false.

Consider now this second example:

int x = 0;
int y = 0;
bool sucess = false;
while (!success) {
    success = do(x, y);
    ++x;
}

Whatever the function do does, and whatever success means, this code doesn't look very safe. You will keep trying forever until something succeeds and do returns true. Are you sure there isn't another terminating condition, such as a maximum time or number of iterations? If you are, go ahead, but it is not a good idea to have a loop in which termination is not evident. Your design should guarantee the termination of the loop, not just suggest it.

If you actually want an infinite loop, because its purpose is to actually run forever or until some external event interrupts it, you should stress it right from the start.

while (true)
{
   ...
}

Using this style you avoid the confusion between the special loops designed to last forever, and the more common loops which are meant to come to an end.

Bibliography

[McConnell 2004]
Steve McConnell: Code Complete, 2nd Edition, Microsoft Press, 2004.

This book discusses loops in Chapter 16: "Loops" (pages 367-389).

[Meyer 1997]
Bertrand Meyer: Object-Oriented Software Construction, 2nd Edition, Prentice Hall, 1997.

Meyer introduces the concepts of loop invariant and loop variant in Chapter 11: "Design by Contract: Building reliable software", section 11.12 "Loop invariants and variants". These concepts are thetheoretic background which allows you to actually prove that your loops will come to an end at their due time.

Comments

Popular posts from this blog

#11. Don't use syntactic overloading

Syntactic overloading (or function overloading) is a C++ feature which allows a class to have several functions with the same name, but with different parameters. To say "Don't use syntactic overloading" is the same as to say "Don't give the same name to different functions".

class C
{
    ...
    void add(int i);
    void add(double d);
    void add(C other);
    ....
}

When you write this client code:

C c;
c.add(x);

The compiler will call the appropiate version of the funcion add, depending on the type of x.

This is what syntactic overloading is. It is called syntactic overloading to distinguish it from semantic overloading 8more properly called dynamic binding), which is the one that happens when you use inheritance and polymorphism.

Syntactic overloading may seem useful at first sight, but it has lots of drawbacks for no real advantage. It just can go wrong in too many ways.

Code is more readable without syntactic overloading. One name for each thing, different n…

#2. Make all type conversions explicit

Assignments, function calls and expressions in general should not contain implicit type conversions. All type conversions should be explicit.

Type conversions should be isolated in their own line, which should consist only of the assignment of the result of the type conversion to a variable of the target type.

A statement should not mix type conversion with other operations. For example, if you need to convert an object to one of another type to pass it as a function parameter, do not do it in the function call itself; instead, do it in a separate instruction in the previous line.
Type conversion occurs when an entity of type A is, well, converted to an entity of type B. This may occur in function calls, expressions using operators, or assignments.
An explicit type conversion is one which you can read in the code. An implicit type conversion is one which does not appear in the source code, but is done automatically when the software is executed.
Making all type conversions explicit he…

#10. Choosing the right loop structure

C++ has three loop instructions: for, while and do ... while. To choose wisely among them, you need to know what their differences are.
1) for A for loop makes sense when you repeat an action for a known number of times, or for all the elements of a known set.

This is the syntax of a forloop:

for (initialization; condition; expression)
{
    statement
}

statement is actually a compound statement, that is, a block of code. This is called the body of the loop. In contrast, the initialization, condition and expression together are called the header of the loop. The initialization is a single statement which ends at the semicolon I wrote after it. The condition is a boolean expression. The expression is a statement. It should be a single statement which modifies one variable which is involved in the condition (see #guideline #5).

The initialization is performed. Then, the condition is evaluated. Then, two things can happen. If the condition is false, the code jumps right after the for statemen…