Follow these guidelines when writing if statements:

Write the nominal path through the code first; then write the unusual cases. Write your code so that the normal path through the code is clear. Make sure that the rare cases don't obscure the normal path of execution. This is important for both readability and performance.

Make sure that you branch correctly on equality. Using > instead of >= or < instead of <= is analogous to making an off-by-one error in accessing an array or computing a loop index. In a loop, think through the endpoints to avoid an off-by-one error. In a conditional statement, think through the equals case to avoid one.

Put the normal case after the if rather than after the else. Put the case you normally expect to process first. This is in line with the general principle of putting code that results from a decision as close as possible to the decision. Here's a code example that does a lot of error processing, haphazardly checking for errors along the way:

OpenFile( inputFile, status )
If ( status = Status_Error ) Then
   errorType = FileOpenError       <-- 1
Else
   ReadFile( inputFile, fileData, status )       <-- 2
   If ( status = Status_Success ) Then
      SummarizeFileData( fileData, summaryData, status )       <-- 3
      If ( status = Status_Error ) Then
         errorType = ErrorType_DataSummaryError       <-- 4
      Else
         PrintSummary( summaryData )       <-- 5
         SaveSummaryData( summaryData, status )
         If ( status = Status_Error ) Then
            errorType = ErrorType_SummarySaveError       <-- 6
         Else
            UpdateAllAccounts()       <-- 7
            EraseUndoFile()
            errorType = ErrorType_None
         End If
      End If
   Else
      errorType = ErrorType_FileReadError
   End If
End If

This code is hard to follow because the nominal cases and the error cases are all mixed together. It's hard to find the path that is normally taken through the code. In addition, because the error conditions are sometimes processed in the if clause rather than the else clause, it's hard to figure out which if test the normal case goes with. In the following rewritten code, the normal path is consistently coded first and all the error cases are coded last. This makes it easier to find and read the nominal case.

OpenFile( inputFile, status )
If ( status = Status_Success ) Then
   ReadFile( inputFile, fileData, status )       <-- 1
   If ( status = Status_Success ) Then
      SummarizeFileData( fileData, summaryData, status )       <-- 2
      If ( status = Status_Success ) Then
         PrintSummary( summaryData )       <-- 3
         SaveSummaryData( summaryData, status )
         If ( status = Status_Success ) Then
            UpdateAllAccounts()       <-- 4
            EraseUndoFile()
            errorType = ErrorType_None
         Else
            errorType = ErrorType_SummarySaveError       <-- 5
         End If
      Else
         errorType = ErrorType_DataSummaryError       <-- 6
      End If
   Else
      errorType = ErrorType_FileReadError       <-- 7
   End If
Else
   errorType = ErrorType_FileOpenError       <-- 8
End If

In the revised example, you can read the main flow of the if tests to find the normal case. The revision puts the focus on reading the main flow rather than on wading through the exceptional cases, so the code is easier to read overall. The stack of error conditions at the bottom of the nest is a sign of well-written error-processing code.

This example illustrates one systematic approach to handling normal cases and error cases. A variety of other solutions to this problem are discussed throughout this book, including using guard clauses, converting to polymorphic dispatch, and extracting the inner part of the test into a separate routine. For a complete list of available approaches, see "Summary of Techniques for Reducing Deep Nesting" in Taming Dangerously Deep Nesting.

Follow the if clause with a meaningful statement. Sometimes you see code like the next example, in which the if clause is null:

Java Example of a Null if Clause

Example 15-3. 

if ( SomeTest )
   ;
else {
   // do something
   ...
}

Most experienced programmers would avoid code like this if only to avoid the work of coding the extra null line and the else line. It looks silly and is easily improved by negating the predicate in the if statement, moving the code from the else clause to the if clause, and eliminating the else clause. Here's how the code would look after those changes:

if ( ! someTest ) {
   // do something
   ...
}

Consider the else clause. If you think you need a plain if statement, consider whether you don't actually need an if-then-else statement. A classic General Motors analysis found that 50 to 80 percent of if statements should have had an else clause (Elshoff 1976).

One option is to code the else clause—with a null statement if necessary—to show that the else case has been considered. Coding null elses just to show that that case has been considered might be overkill, but at the very least, take the else case into account. When you have an if test without an else, unless the reason is obvious, use comments to explain why the else clause isn't necessary, like so:

// if color is valid
if ( COLOR_MIN <= color && color <= COLOR_MAX ) {
   // do something
   ...
}
else {
   // else color is invalid
   // screen not written to --- safely ignore command
}

Test the else clause for correctness. When testing your code, you might think that the main clause, the if, is all that needs to be tested. If it's possible to test the else clause, however, be sure to do that.

Check for reversal of the if and else clauses. A common mistake in programming if-thens 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 the if test backward. Check your code for this common error.

In languages that don't support case statements—or that support them only partially— you'll often find yourself writing chains of if-then-else tests. For example, the code to categorize a character might use a chain like this one:

if ( inputCharacter < SPACE ) {
   characterType = CharacterType_ControlCharacter;
}
else if (
   inputCharacter == ' ' ||
   inputCharacter == ',' ||
   inputCharacter == '.' ||
   inputCharacter == '!' ||
   inputCharacter == '(' ||
   inputCharacter == ')' ||
   inputCharacter == ':' ||
   inputCharacter == ';' ||
   inputCharacter == '?' ||
   inputCharacter == '-'
   ) {
   characterType = CharacterType_Punctuation;
}
else if ( '0' <= inputCharacter && inputCharacter <= '9' ) {
   characterType = CharacterType_Digit;
}
else if (
   ( 'a' <= inputCharacter && inputCharacter <= 'z' ) ||
   ( 'A' <= inputCharacter && inputCharacter <= 'Z' )
   ) {
   characterType = CharacterType_Letter;
}

Consider these guidelines when writing such if-then-else chains:

Simplify complicated tests with boolean function calls. One reason the code in the previous example is hard to read is that the tests that categorize the character are complicated. To improve readability, you can replace them with calls to boolean functions. Here's how the example's code looks when the tests are replaced with boolean functions:

if ( IsControl( inputCharacter ) ) {
   characterType = CharacterType_ControlCharacter;
}
else if ( IsPunctuation( inputCharacter ) ) {
   characterType = CharacterType_Punctuation;
}
else if ( IsDigit( inputCharacter ) ) {
   characterType = CharacterType_Digit;
}
else if ( IsLetter( inputCharacter ) ) {
   characterType = CharacterType_Letter;
}

Put the most common cases first. By putting the most common cases first, 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 the most common cases. In the example just shown, letters would be more common than punctuation but the test for punctuation is made first. Here's the code revised so that it tests for letters first:

if ( IsLetter( inputCharacter ) ) {       <-- 1
   characterType = CharacterType_Letter;
}
else if ( IsPunctuation( inputCharacter ) ) {
   characterType = CharacterType_Punctuation;
}
else if ( IsDigit( inputCharacter ) ) {
   characterType = CharacterType_Digit;
}
else if ( IsControl( inputCharacter ) ) {       <-- 2
   characterType = CharacterType_ControlCharacter;
}

Make sure that all cases are covered. Code a final else clause with an error message or assertion to catch cases you didn't plan for. This error message is intended for you rather than for the user, so word it appropriately. Here's how you can modify the character-classification example to perform an "other cases" test:

if ( IsLetter( inputCharacter ) ) {
   characterType = CharacterType_Letter;
}
else if ( IsPunctuation( inputCharacter ) ) {
   characterType = CharacterType_Punctuation;
}
else if ( IsDigit( inputCharacter ) ) {
   characterType = CharacterType_Digit;
}
else if ( IsControl( inputCharacter ) ) {
   characterType = CharacterType_ControlCharacter;
}
else {
   DisplayInternalError( "Unexpected type of character detected." );
}

Replace if-then-else chains with other constructs if your language supports them. A few languages—Microsoft Visual Basic and Ada, for example—provide case statements that support use of strings, enums, and logical functions. Use them—they are easier to code and easier to read than if-then-else chains. Code for classifying character types by using a case statement in Visual Basic would be written like this:

Select Case inputCharacter
   Case "a" To "z"
      characterType = CharacterType_Letter
   Case " ", ",", ".", "!", "(", ")", ":", ";", "?", "-"
      characterType = CharacterType_Punctuation
   Case "0" To "9"
      characterType = CharacterType_Digit
   Case FIRST_CONTROL_CHARACTER To LAST_CONTROL_CHARACTER
      characterType = CharacterType_Control
   Case Else
      DisplayInternalError( "Unexpected type of character detected." )
End Select