Robert’s Rules of Coders #9: Eliminate Deep Nesting by Using Switch Statements and Functions

The ‘If’ statement is one of the fundamental coding constructs of almost every programming language. Along with the ‘If’ statement, most languages also support ‘else’ conditions and the ability to nest ‘If’ statements. But this simple construct can also become one of the biggest contributors to code that is difficult to understand and modify. This often happens when ‘If’ statements get nested within ‘If’ statements; but there are two simple techniques you can use to reduce this complexity, ‘Switch’ statements and functions.

Switch statements offer these benefits to most developers:

• They are easier to read, and thus
• They are easier to understand, and thus
• They are easier to maintain.
• They are also easier to debug.
• In many languages, they also can be compiled to execute a little more swiftly than nested ‘If’ statements

Here is an example of an ‘If’ statement than can be improved by converting it to a ‘Switch’ statement:

Quote:

• If aValue = 6 then
  • Stars = stars + 1
• Else
  • if aValue = 7
    • Stars = stars + 3
  • Else
    • if aValue = 8
      • Stars = stars + 5
    • Else
      • if aValue = 9
        • Stars = stars + 9
      • End if
    • End if
  • End if
• End if

Here is the same logic from above, using a ‘Switch’ statement:

Quote:

• Switch aValue
  • Case 6:
    • Stars = Stars + 1
  • Case 7:
    • Stars = Stars + 3
  • Case 8:
    • Stars = Stars + 5
  • Case 9:
    • Stars = Stars + 9

I suspect that you will agree that it is easier to understand the code in the switch statement than the code in the nested ‘If’s. Another technique to eliminate nested ‘If’ statements is to move some of the code into separate functions. Although the hierarchy of ‘If’ statements may remain the same from the computer’s point of view, to most humans, it becomes much easier to manage.

Quote:

• If input data is valid
  • If filename is valid
    • Create File
    • If file was created
      • Log “Success”
      • Return “Success”
    • Else
      • If error due to size
        • Log “Failure”
        • Return “Could not create file because it is too large.”
      • If error due to permission
        • Log “Failure”
        • Return “Could not create file because you do not have permissions.”
      • Else
        • Log “Failure”
        • Return “Unable to create the file. Reason unknown.”
      • End if
    • End if
  • Else
    • Log “Failure”
    • Return “Your file name is invalid.”
  • End if
• Else
  • Log “Failure”
  • Return “The file input is invalid.”
• End if

Here is the same logic from above, using functions:

Quote:

• String response = “”
• Response = IsInputValid(myinput)
• If (response= “”)
  • Return response
• Response = IsFileNameValid(myfile)
• If (response= “”)
  • Return response
• return FileCreationResultMessage(myfile, myinput)

The functions called from the code above:

Quote:

• Function string IsInputValid(string input)
  • If input is not valid
    • Log “Failure”
    • Return “The file input is invalid.”
  • Else
    • Return “”
  • End if
• End Function
•  
• Function string IsFileNameValid(string input)
  • If input is not valid
    • Log “Failure”
    • Return “Your file name is invalid.”
  • Else
    • Return “”
  • End if
• End Function
•  
• Function string FileCreationResultMessage(string file, string input)
  • Create File
    • If file was created
      • Log “Success”
      • Return “Success”
    • Else
      • If error due to size
        • Log “Failure”
        • Return “Could not create file because it is too large.”
      • If error due to permission
        • Log “Failure”
        • Return “Could not create file because you do not have permissions.”
      • Else
        • Log “Failure”
        • Return “Unable to create the file. Reason unknown.”
      • End if
    • End if
• End Function

As with any of Robert’s Rules of Coding, you don’t need to adhere to them all of the time and there are cases where it is better not to. But most programmers should follow the rules most of the time. I hope you agree.

Go to Robert’s Rules of Coders for more.