Most languages support some means of exiting from a routine partway through the routine. The return and exit statements are control constructs that enable a program to exit from a routine at will. They cause the routine to terminate through the normal exit channel, returning control to the calling routine. The word return is used here as a generic term for return in C++ and Java, Exit Sub and Exit Function in Microsoft Visual Basic, and similar constructs. Here are guidelines for using the return statement:

Use a return when it enhances readability. In certain routines, once you know the answer, you want to return it to the calling routine immediately. If the routine is defined in such a way that it doesn't require any further cleanup once it detects an error, not returning immediately means that you have to write more code.

The following is a good example of a case in which returning from multiple places in a routine makes sense:

Comparison Compare( int value1, int value2 ) {       <-- 1
   if ( value1 < value2 ) {
      return Comparison_LessThan;
   }
   else if ( value1 > value2 ) {
      return Comparison_GreaterThan;
   }
   return Comparison_Equal;
}

Other examples are less clear-cut, as the next subsection illustrates.

Use guard clauses (early returns or exits) to simplify complex error processing. Code that has to check for numerous error conditions before performing its nominal actions can result in deeply indented code and can obscure the nominal case, as shown here:

If file.validName() Then
   If file.Open() Then
      If encryptionKey.valid() Then
         If file.Decrypt( encryptionKey ) Then
            ' lots of code       <-- 1
            ...
         End If
      End If
   End If
End If

Indenting the main body of the routine inside four if statements is aesthetically ugly, especially if there's much code inside the innermost if statement. In such cases, the flow of the code is sometimes clearer if the erroneous cases are checked first, clearing the way for the nominal path through the code. Here's how that might look:

' set up, bailing out if errors are found
If Not file.validName() Then Exit Sub
If Not file.Open() Then Exit Sub
If Not encryptionKey.valid() Then Exit Sub
If Not file.Decrypt( encryptionKey ) Then Exit Sub

' lots of code
...

This simple code makes this technique look like a tidy solution, but production code often requires more extensive housekeeping or cleanup when an error condition is detected. Here is a more realistic example:

' set up, bailing out if errors are found
If Not file.validName() Then
   errorStatus = FileError_InvalidFileName
   Exit Sub
End If

If Not file.Open() Then
   errorStatus = FileError_CantOpenFile
   Exit Sub
End If

If Not encryptionKey.valid() Then
   errorStatus = FileError_InvalidEncryptionKey
   Exit Sub
End If

If Not file.Decrypt( encryptionKey ) Then
   errorStatus = FileError_CantDecryptFile
   Exit Sub
End If

' lots of code       <-- 1
...

With production-size code, the Exit Sub approach creates a noticeable amount of code before the nominal case is handled. The Exit Sub approach does avoid the deep nesting of the first example, however, and, if the code in the first example were expanded to show setting an errorStatus variable, the Exit Sub approach would do a better job of keeping related statements together. When all the dust settles, the Exit Sub approach does appear more readable and maintainable, just not by a very wide margin.

Minimize the number of returns in each routine. It's harder to understand a routine when, reading it at the bottom, you're unaware of the possibility that it returned some-where above. For that reason, use returns judiciously—only when they improve readability.