Programming

Code Complete 2 – Steve McConnell – Using Conditionals

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:

A conditional is a statement that controls the execution of other statements; execution of the other statements is “conditioned” on statements such as if, else, case and switch.

Guidelines for if statements

  • Write the normal path through the code first; then write the unusual cases
  • Make sure that you branch correctly on equality – using > instead of >= or < instead of <= is analogous to making an off-by-one error.
  • Put the normal case after the if rather than after the else – put the case you normally expect to process first.
  • Check for reversal of the if and else clauses – a common mistake in programming if-else statements is to flip-flop the code that’s supposed to follow the if clause and the code that’s supposed to follow the else clause or to get the logic of if test backward.

Guidelines for if-else if statements

  • Simplify complicated tests with boolean function calls – To improve readability, you can replace them with calls to boolean functions, here’s example without boolean function calls. 
    if ( 
    ('a' <= inputCharacter && inputCharacter <= 'z') || 
    ('A' <= inputCharacter && inputCharacter <= 'Z')    
    ) {
    // do something...
}

    and here is the code simplified:

    if ( isLetter( inputCharacter) ) {
    // do something
}
  • Put the most common cases first – That way you minimize the amount of exception-case handling code someone has to read to find the usual cases. You improve efficiency because you minimize the number of tests the code does to find most common cases.
  • Make sure that all cases are covered – Code the final _else clause with an error message or assertion to catch cases you didn’t plan for.

Case statements

Choosing the most effective ordering of cases

If you have a long _case` statement that handles dozens of events in an event-driven program, the order is significant. Following are some ordering possibilities:
+ Order cases alphabetically or numerically – If cases are equally important, putting them in A-B-C order improves readability.

  • Put the normal case first – If you have a normal case and several exceptions, put the normal case first.

  • Order cases by frequency – Put the most frequently executed cases first and the least frequently executed last.

Tips for using case statements

  • Keep the actions of each case simple – short code following each case helps make the structure of the case statement clear. If actions performed for a case are complicated, write a routine and call the routine from the case rather than putting the code into the case itself.

  • Use the default clause only to detect legitimate defaults – you might sometimes have only one case remaining and decide to code that case as the default clause. Though sometimes tempting, that’s dumb. You lose the automatic documentation provided by case-statement labels, and you lose the ability to detect errors with the default clause.

  • Use the default clause to detect errors – if the default clause is used for some purpose other than error detection, the implication is that every case selector is correct.

  • Avoid dropping through the end of a case statement – languages like C, C++, and Java don’t automatically break out of each case. If you don’t code the end of the case, the program drops through the end and executes the code for the next case.

  • Clearly and unmistakably identify flow-throughs at the end of a case – if you intentionally write code to drop through the end of a case, clearly comment the place at which it happens and explain why it needs to be coded that way. This technique should be avoided.

Written by Nikola Brežnjak