How would you refactor nested IF Statements?
- by saunderl
I was cruising around the programming blogosphere when I happened upon this post about GOTO's:
http://giuliozambon.blogspot.com/2010/12/programmers-tabu.html
Here the writer talks about how "one must come to the conclusion that there are situations where GOTOs make for more readable and more maintainable code" and then goes on to show an example similar to this:
if (Check#1)
{
CodeBlock#1
if (Check#2)
{
CodeBlock#2
if (Check#3)
{
CodeBlock#3
if (Check#4)
{
CodeBlock#4
if (Check#5)
{
CodeBlock#5
if (Check#6)
{
CodeBlock#6
if (Check#7)
{
CodeBlock#7
}
else
{
rest - of - the - program
}
}
}
}
}
}
}
The writer then proposes that using GOTO's would make this code much easier to read and maintain.
I personally can think of at least 3 different ways to flatten it out and make this code more readable without resorting to flow-breaking GOTO's. Here are my two favorites.
1 - Nested Small Functions. Take each if and its code block and turn it into a function. If the boolean check fails, just return. If it passes, then call the next function in the chain. (Boy, that sounds a lot like recursion, could you do it in a single loop with function pointers?)
2 - Sentinal Variable. To me this is the easyest. Just use a blnContinueProcessing variable and check to see if it is still true in your if check. Then if the check fails, set the variable to false.
How many different ways can this type of coding problem be refactored to reduce nesting and increase maintainability?
