Avoid using ifs

The use of ifs or conditionals in programming may seem like something really important at first, and for beginners it really is, but as you gain experience, you will notice that you need to know how to use it wisely.

The excessive use of conditionals in programming makes code smell and difficult to change. This article demonstrates some techniques on how to avoid the use of ifs, proposing more flexible and robust solutions that will make the code cleaner, more changeable and testable.

Cyclomatic Complexity

Cyclomatic complexity is a metric used to quantify the complexity of a program, measuring the number of possible independent paths through the code. It is an important metric in software engineering because it indicates the level of difficulty of maintaining, testing and understanding a program. The greater the cyclomatic complexity, the more difficult it will be to test and maintain the code, as it will have more possible execution flows.

Definition

Formally, cyclomatic complexity is defined as the number of linearly independent paths through a program, that is, the minimum number of test cases required to cover each possible path of the program.

The formula for calculating the cyclomatic complexity of a control flow graph is: V(G)=E−N+2PV(G) = E — N + 2PV(G)=E−N+2

Where:

• E is the number of edges (control transitions, like “arrows” in the code flow).
• N is the number of nodes (statements or blocks of code, like “boxes” in the flow).
• P is the number of connected components (typically 1 if you are dealing with a single program or function).

How It Works

To understand better, consider a simple block of code that contains conditionals and loops. With each conditional decision (if, else, switch, etc.) or loop (for, while), the number of independent paths increases.

Impact of “if-else or switch-case” on Cyclomatic Complexity

Each if, else if, or switch in a code adds at least one new path to the control flow graph, increasing cyclomatic complexity. For example, a code full of payment type checks:

public string GetPaymentType(PaymentType paymentType)
{
    return paymentType switch
    {
        PaymentType.CreditCard => nameof(PaymentType.CreditCard),
        PaymentType.DebitCard => nameof(PaymentType.DebitCard),
        PaymentType.Cash => nameof(PaymentType.Cash),
        PaymentType.Pix => nameof(PaymentType.Pix),
        PaymentType.Bill => nameof(PaymentType.Bill),
       _ => string.Empty,
    };
}

Here, each condition adds a new path to the code, increasing the cyclomatic complexity, which in this case would be 6 (one path for each payment type). If we keep adding more checks, this complexity can quickly increase, making the code harder to test and maintain.

Avoiding “if-else or switch-case” with Design Approaches

An effective way to reduce the use of if-else or switch-case in cyclomatic complexity is to replace conditional structures with polymorphism, using inheritance, interfaces and design strategies such as the Strategy or Factory pattern. Below we will highlight some practical approaches, showing how to avoid the use of ifs.

1 .Using Polymorphism (Interfaces/Inheritance)

1.1 Using Inheritance

Instead of using if-else or switch-case to check the payment type, we can use polymorphism. This makes the code simpler and the execution logic more flexible and decoupled.

This example will highlight the use of polymorphism with the abstract Payment class. It helps to avoid using multiple conditionals (ifs) to check the payment type, because you can use the concept of inheritance and method overloading.

The Payment class is an abstract class that defines the Pay method, which will be implemented by all payment-specific subclasses, such as CreditCardPayment, DebitCardPayment, CashPayment, among others. Since all these subclasses inherit from Payment and implement their own versions of the Pay method, the code that processes payments does not need to check what the specific payment type is.

Without polymorphism, a conditional block with several ifs would be needed to identify the payment type (e.g.: credit card, debit card, Pix, etc.) and then call the appropriate method, as described in the code approach below:

if (paymentType == PaymentType.CreditCard) 
{
    // Process credit card payment
} else if (paymentType == PaymentType.DebitCard) 
{
    // Process debit card payment
} //and so on for each type

With polymorphism, the code becomes simpler and more flexible, since it is enough to call the Pay method of the payment object, and the correct implementation will be used automatically, based on the type of the instance:

payment.Pay();

Each payment type (CreditCardPayment, PixPayment, etc.) implements the Pay method according to its own logic, without the need to explicitly check the payment type. This makes the code cleaner, easier to maintain, and allows new payment types to be added in the future without changing the existing code (open for extension, closed for modification — SOLID principle).

1.2 Interface usage

Using the IPayment interface also eliminates the need for conditionals such as if or switch, this is done by taking advantage of the concept of polymorphism through interfaces.
The IPayment interface defines a contract that all payment classes must follow. In this case, the interface requires classes to implement the Payment method, but does not define how this method will be implemented. Each concrete class (CreditCardPayment, DebitCardPayment, PixPayment, etc.) must provide its own implementation of the Payment method.

How the IPayment interface helps you avoid conditionals:

When you define an interface, the code that consumes that interface doesn’t need to worry about the specific type of the class that implements the interface. It just needs to know that any class that implements the interface will have the Payment method. This eliminates the need to check the type of the class (with an if or switch statement) to execute the appropriate method.

For example, without using an interface, the code might look like this:

if (paymentType == PaymentType.CreditCard)
{
// Processes payment with credit card
} else if (paymentType == PaymentType.Pix)
{
// Processes payment with Pix
} else if (paymentType == PaymentType.Cash)
{
// Processes payment with cash
}

When the IPayment interface is implemented, the code can be more generic:

public void Payment(IPayment payment)
{
    payment.Payment();
}

When implementing the IPayment interface, the Payment method is called. It doesn’t matter if the payment is by credit card, debit card, Pix or any other method: each of them has its own implementation of Payment and polymorphism takes care of calling the correct method, depending on the object instance.

Benefits of using the interface:

1. Simpler and more flexible code: No need for conditionals to check the payment type.
2. Easy to add new payment methods: If you need to add a new payment type, simply create a new class that implements IPayment and provide an implementation for the Payment method. No modifications to the code that processes payments will be necessary..
3. Security and consistency: Guarantee that all payment classes will have the Payment method, because they all implement the interface.

Difference between interface and abstract Payment class:

While an abstract class like Payment can provide some default implementations of methods (and only allows single inheritance), an interface is a more flexible contract that any class can implement, even if it already inherits from another class. This can be useful if you want unrelated classes to share a common behavior.

In short, by using the IPayment interface, you can treat all payment methods in a uniform way, delegating the specific implementation of each payment type to the concrete classes, without needing conditional blocks in the code.

1.3 Avoiding the use of ifs with a dictionary

public static class PaymentHelper
 {
     public static Dictionary<PaymentType, Payment> PaymentsClasses = new()
     {
         { PaymentType.CreditCard,  new CreditCardPayment() },
         { PaymentType.DebitCard, new DebitCardPayment() },
         { PaymentType.Cash, new CashPayment() },
          { PaymentType.Pix, new PixPayment() },
          { PaymentType.Bill, new BillPayment() }
     };

     public static Dictionary<PaymentType, IPayment> PaymentsInterfaces = new()
     {
         { PaymentType.CreditCard, new CreditCardPayment() },
         { PaymentType.DebitCard, new DebitCardPayment() },
         { PaymentType.Cash, new CashPayment() },
         { PaymentType.Pix, new PixPayment() },
         { PaymentType.Bill, new BillPayment() }
      };
 }

he PaymentHelper class code uses a Dictionary to map the payment types defined in the PaymentType enumeration to their respective payment implementations, either through concrete classes (Payment) or interfaces (IPayment). This approach helps to avoid using conditionals such as if or switch to determine which payment class should be instantiated based on the payment type.

Code Explanation:

1 Dictionaries (Dictionary<PaymentType, Payment> and Dictionary<PaymentType, IPayment>):

• The code defines two static dictionaries:
• PaymentsClasses: Maps a PaymentType (such as CreditCard, DebitCard, etc.) to a concrete instance of a class that inherits from Payment.
• PaymentsInterfaces: Maps a PaymentType to an instance of a class that implements the IPayment interface..

2 Each dictionary does the following:

• The dictionary keys are the values ​​of the PaymentType enumeration, which represent the different payment types (Credit Card, Debit Card, Cash, Pix, etc.).
• The values ​​are instances of concrete classes, such as CreditCardPayment, DebitCardPayment, CashPayment, etc.

3 How this avoids the use of if:

• No dictionary: If you didn’t use a dictionary, to choose the appropriate payment class based on the payment type, you would probably use an if-else block or a switch, checking the payment type and manually instantiating the corresponding class.
• Something like:

if (paymentType == PaymentType.CreditCard)
{
    payment = new CreditCardPayment();
} else if (paymentType == PaymentType.DebitCard)
{
    payment = new DebitCardPayment();
}

• With dictionary: By using a dictionary, you eliminate the need for this conditional code. Instead, you simply look up the dictionary to get the correct class:

var payment = PaymentHelper.PaymentsClasses[paymentType];

1. The dictionary already knows which implementation to use for each payment type, so there is no need for a conditional..
2. Benefits:

• Extensibility: Adding new payment types is easy. Just add a new entry to the dictionary. There is no need to modify an existing if or switch block..
• Maintainability: The code is easier to maintain, since you concentrate the mapping logic in one place (the dictionary), and the rest of the code simply consumes the dictionary.
• Polymorphism: Once you have the correct instance of the payment class (whether it is a concrete class or one that implements IPayment), you can call methods like Pay() or Payment if it is the interface, directly without having to worry about the specific class type.

Usage Example:

With the dictionary, instead of using conditionals to determine the payment type, you would do something like this:

PaymentType paymentType = PaymentType.CreditCard;
var payment = PaymentHelper.PaymentsClasses[paymentType];
payment.Pay();

Or, if you are using the IPayment interface:

PaymentType paymentType = PaymentType.Pix;
var payment = PaymentHelper.PaymentsInterfaces[paymentType];
payment.Payment();

In this example, the code is more direct and without conditionals, since the dictionary does the “magic” of returning the correct instance automatically based on the payment type.

Class diagram:

Conclusion

Cyclomatic complexity can be significantly reduced by eliminating the use of conditionals (if-else) through good design practices such as polymorphism (with inheritance or use of interfaces), the Strategy pattern, and the use of dictionaries to map behaviors. This leads to simpler, more testable, easy to maintain, and extensible code, without the need to change existing code when adding new types of functionality.

References: Clean Code — Guia e Exemplos | balta.io

Esta é a regra MAIS IMPORTANTE do Clean Code! | #dev #code #programação #balta (youtube.com)

Github: https://github.com/carsimoes/avoid-if

Authors:

Rafael Sandim Kretzchmar (https://medium.com/@rafaelsandimkretzschmar/avoid-using-ifs-75de8c4a865f)

Carlos Renato Simões