Code Smell 102 - Arrow Code
Nested IFs and Elses are very hard to read and test
TL;DR: Avoid nested IFs. Even Better: Avoid ALL IFs
Problems
- Readability
Solutions
Extract Method
Combine Boolean Conditions
Remove accidental IFs
Context
In procedural code, it is very common to see complex nested ifs. This is more related to scripting than object-oriented programming.
Sample Code
Wrong
if (actualIndex < totalItems)
{
if (product[actualIndex].Name.Contains("arrow"))
{
do
{
if (product[actualIndex].price == null)
{
// handle no price
}
else
{
if (!(product[actualIndex].priceIsCurrent()))
{
// add price
}
else
{
if (!hasDiscount)
{
// handle discount
}
else
{
// etc
}
}
}
actualIndex++;
}
while (actualIndex < totalCounf && totalPrice < wallet.money);
}
else
actualIndex++;
}
return actualIndex;
}
Right
foreach (products as currentProduct)
addPriceIfDefined(currentProduct)
addPriceIfDefined()
{
//Several extracts
}
Detection
[X] Automatic
Since many linters can parse trees we can check on compile-time for nesting levels.
Tags
Readability
Complexity
Conclusion
Following uncle bob's advice, we should leave the code cleaner than we found it.
Refactoring this problem is easy.
Relations
More Info
The purpose of software engineering is to control complexity, not to create it.
Pamela Zave
This article is part of the CodeSmell Series.
Oldest comments (0)