c# if statement: Practical Usage and Code Examples

The c# if statement is the most direct way to branch execution based on a boolean condition. In its simplest form, it evaluates an expression and runs a block of code only when that expression is true. Consider a method that returns a discount based on order size:

public decimal CalculateDiscount(int quantity)
{
    decimal discount = 0m;
    if (quantity >= 100)
    {
        discount = 0.10m;
    }
    return discount;
}

The condition quantity >= 100 is a boolean expression. If it evaluates to true, the block assigns 10% to discount. If it is false, the block is skipped entirely. This is the foundation of all conditional logic in C#.

Adding else and else if Branches

Real conditions usually need more than one outcome. The else keyword provides an alternative path when the initial condition is false:

if (quantity >= 100)
{
    discount = 0.10m;
}
else
{
    discount = 0.05m;
}

When you have multiple mutually exclusive possibilities, chain conditions with else if:

if (quantity >= 200)
{
    discount = 0.15m;
}
else if (quantity >= 100)
{
    discount = 0.10m;
}
else if (quantity >= 50)
{
    discount = 0.05m;
}
else
{
    discount = 0m;
}

Order matters. The runtime evaluates conditions top-down and stops at the first true one. If you placed quantity >= 50 before quantity >= 100, a quantity of 150 would incorrectly match the 5% branch. Always arrange conditions from most restrictive to least restrictive, or use explicit boundaries.

Braces and Single-Statement Form

C# allows you to omit braces when a branch contains only one statement:

if (quantity >= 100)
    discount = 0.10m;
else
    discount = 0.05m;

This works, but it is risky. A common refactor accidentally changes which statements belong to which branch:

if (quantity >= 100)
    discount = 0.10m;
    ApplyLoyaltyBonus();  // Always runs!
else
    discount = 0.05m;    // Syntax error: else without matching if

The second statement is not part of the if block because only discount = 0.10m; is. The ApplyLoyaltyBonus() call always runs, and the else no longer has a matching if. Always using braces removes this ambiguity and makes the intended structure explicit.

Boolean Expressions and Common Mistakes

An if condition must be a boolean expression. Unlike some languages, C# does not implicitly convert integers or objects to bool. The following will not compile:

int count = 0;
if (count)   // Compiler error: cannot convert int to bool
{
    // ...
}

You must write an explicit comparison:

if (count != 0)

A frequent real-world bug is using a single = instead of == for equality:

if (count = 10)  // Assignment, not comparison; compile error because int is not bool

In C#, this is caught at compile time because assignment returns an int, not a bool. This is a world apart from languages that allow accidental assignment in conditions. It is still a mistake, but the compiler helps you catch it.

Another common issue is confusing & and && in conditions. The single & performs bitwise AND on integers, but when applied to booleans it still works, yet it evaluates both sides always. The short-circuit && skips the right operand if the left is false. In practice, short-circuiting matters for both performance and correctness:

if (items != null && items.Length > 0)
{
    // Safe to access items.Length
}

Using & here would evaluate items.Length even when items is null, causing a NullReferenceException. Always use && (and ||) unless you specifically need both sides evaluated (for example, because the right side has a required side effect).

Nested If and Early Return

Nesting if statements is sometimes necessary, but deep nesting quickly becomes hard to follow. Consider this data validation pattern:

if (order != null)
{
    if (order.Items.Count > 0)
    {
        if (order.Customer.IsActive)
        {
            // Process order
        }
    }
}

Each level adds cognitive overhead. In many methods, early returns reduce nesting and improve readability:

if (order == null) return;
if (order.Items.Count == 0) return;
if (!order.Customer.IsActive) return;

// Process order

The early-return version keeps each condition on its own line and avoids indentation pyramids. Use this pattern when a method has multiple independent preconditions. It also makes the guard conditions explicit to future maintainers.

Short-Circuiting and Side Effects

Short-circuiting does not only prevent null-reference errors—it also affects performance and behavior when conditions have side effects. The right-hand operand is not evaluated if the left-hand already determines the result:

if (IsValid(input) && SaveToDatabase(input))
{
    // ...
}

Here SaveToDatabase only runs when IsValid returns true. That is a deliberate control-flow decision. If you need both calls to run regardless of the first result, rearrange the logic or use nested if statements. Do not rely on the evaluation order without understanding which operand will be skipped.

When a switch Might Be Cleaner

An if-else chain that only compares one variable against several constant values is often better replaced with a switch expression. For example:

string category = quantity switch
{
    >= 1000 => "Wholesale",
    >= 100  => "Large",
    >= 10   => "Standard",
    _       => "Small"
};

The switch expression is concise and guarantees that only one branch applies, similar to if-else but with a more declarative shape. Use it when the condition is a single value and the branches are straightforward constants or relational patterns. If your conditions compare multiple independent values or call methods, stick with if-else.

Performance Considerations in Hot Paths

In most business applications, if statement costs are negligible because the condition evaluates in nanoseconds. However, in tight loops or frequently called methods, avoid placing expensive method calls inside the condition if they are not necessary. For example:

if (cache.Get(key) != null && cache.Get(key).Value > threshold)

The cache is hit twice. Store the result in a local variable to avoid repeated lookup:

var cached = cache.Get(key);
if (cached != null && cached.Value > threshold)

This is a minor optimization, but it prevents side effects and double work. The compiler may not inline the method call, so the behavior is not guaranteed to be deduplicated. In high-frequency paths, such micro-optimizations can add up, but always measure before changing for performance reasons. The primary benefit here is correctness—you avoid relying on the cache returning the same object each call.

Edge Cases: Equality with Floating-Point Values

When comparing double or float values, using == can produce subtly wrong results due to rounding. For example:

double x = 0.1 + 0.2;
if (x == 0.3)  // Often false because x is 0.30000000000000004

Instead, compare against a tolerance:

if (Math.Abs(x - 0.3) < 1e-9)

This is relevant when the condition depends on computed floating-point values. For decimal types, == is safe because decimal represents base-10 numbers exactly. Choose the appropriate type for your domain; for monetary calculations, use decimal rather than double to avoid such edge cases altogether.

Conditional Access and Null Checks

A frequent pattern in modern C# is combining the if statement with null-conditional operators to avoid verbose null checks:

if (customer?.Address?.City == "Seattle")
{
    // ...
}

This single condition safely navigates the object graph. If any link is null, the whole expression evaluates to null, which does not equal "Seattle", so the block is skipped. This is much shorter than nested ifs and clearly expresses the intent. Use it when you need to check a value deep inside a hierarchy without worrying about intermediate nulls.

Maintainability: Keep Conditions Readable

Complex conditions hurt readability. Extract them into well-named methods:

if (order.IsEligibleForExpeditedShipping())
{
    // ...
}

private bool IsEligibleForExpeditedShipping()
{
    return OrderTotal > 500 && CountryCode == "US" && !IsHoliday;
}

The calling code reads like English, and the logic lives in one place. This also makes unit testing easier because the condition is isolated. Avoid inlining many compound conditions directly inside an if unless they are trivial.

A related tip: avoid negated conditions where possible. Prefer if (customer.IsActive) over if (!customer.IsInactive). Double negatives are hard to parse. If you must use negation, consider renaming the property or method to express the positive concept.