Conditionals and Loops in Solidity

Analogy categoryAnalogies

Control Flow in a Gas-Metered World

Solidity borrows its control-flow syntax almost directly from JavaScript and C: you branch with if, else if, and else, and you repeat work with for, while, and do-while. The crucial difference from ordinary languages is that every opcode a branch or loop executes costs gas, which is paid for in real money by whoever sends the transaction. Control flow is therefore not just a logic concern but an economic one — a poorly bounded loop can make a function permanently unusable.

🏏

Cricket analogy: Like a captain rotating bowlers over an innings, each if branch commits you to a plan; but in Solidity every delivery bowled also drains a fixed budget, so an over that never ends bankrupts the team.

Branching with if / else

Solidity's if requires a boolean expression — unlike C, you cannot pass an integer and rely on non-zero being truthy. There is no ternary shorthand-free 'truthiness' coercion, so if (balance) is a compile error while if (balance > 0) is correct. You can chain else if and close with else, and braces are optional for single statements but strongly recommended to avoid dangling-else bugs. Because Solidity has no exceptions in the try/catch sense for internal logic, if combined with require is the primary way to guard state changes.

🏏

Cricket analogy: A DRS review only triggers on a strict boolean 'is it out?' — Solidity's if is the same, refusing the vague 'looked close' that a raw integer would be.

Loops and the Gas-Limit Trap

Solidity supports for, while, and do-while with break and continue behaving as expected. The danger is that iterating over a dynamically sized array whose length is controlled by users can exceed the block gas limit, causing every call to revert — a denial-of-service. The standard mitigation is the pull-over-push pattern and pagination: instead of looping over all recipients to send funds, let each recipient withdraw individually, or process a bounded slice per transaction. Never write a loop whose iteration count grows without a hard cap you control.

🏏

Cricket analogy: Trying to bat all 90 overs in a single unbroken spell is impossible; you pace it session by session, exactly as you paginate a Solidity loop instead of processing every record at once.

solidity

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract ControlFlow {
    mapping(address => uint256) public pendingWithdrawals;

    // Bad: loops over an unbounded, user-controlled array
    function payAll(address[] calldata users) external {
        for (uint256 i = 0; i < users.length; i++) {
            payable(users[i]).transfer(1 ether); // one bad address reverts all
        }
    }

    // Good: pull pattern — each user withdraws their own funds
    function withdraw() external {
        uint256 amount = pendingWithdrawals[msg.sender];
        require(amount > 0, "nothing to withdraw");
        pendingWithdrawals[msg.sender] = 0; // effects before interaction
        payable(msg.sender).transfer(amount);
    }

    // Branching with an explicit boolean, plus break/continue
    function firstEvenAbove(uint256[] calldata xs, uint256 min)
        external
        pure
        returns (uint256 found)
    {
        for (uint256 i = 0; i < xs.length; i++) {
            if (xs[i] <= min) {
                continue; // skip small values
            }
            if (xs[i] % 2 == 0) {
                found = xs[i];
                break; // stop at first match
            }
        }
    }
}

A loop bounded by array.length where the array grows without limit is a classic denial-of-service vulnerability. If a single element can cause a revert (for example a recipient whose fallback reverts on receiving Ether), the entire batch fails and can lock the contract. Prefer the pull-over-push withdrawal pattern.

One subtlety unique to Solidity is that reading and writing storage inside a loop is extremely expensive (a cold SLOAD is 2100 gas and an SSTORE can cost 20000 gas for a zero-to-nonzero write). A common optimization is to cache a storage variable into a local memory variable before the loop, mutate the local copy each iteration, and write back once after the loop finishes. This can cut the gas cost of an iterating function by an order of magnitude when many iterations touch the same slot.

🏏

Cricket analogy: Rather than running to the pavilion after every single, you accumulate runs at the crease and only update the scoreboard between overs — caching storage writes outside the loop works identically.

Solidity 0.8+ has built-in overflow and underflow checks, so a loop counter that wraps around will revert rather than silently loop forever. You can opt out inside an unchecked { } block for a small gas saving on counters you have proven cannot overflow, such as i++ bounded by an array length.

Solidity's if requires a real boolean — integers are not truthy, so use explicit comparisons like x > 0.
for, while, and do-while all exist and support break and continue as in C-style languages.
Every executed branch and iteration costs gas, making control flow an economic decision, not just a logical one.
Loops over unbounded, user-controlled arrays are a denial-of-service risk; use pagination or the pull-over-push pattern.
Cache storage into a memory local, mutate in the loop, and write back once to save large amounts of gas.
Solidity 0.8+ reverts on overflow by default; use unchecked only for counters proven safe.
Prefer letting users withdraw their own funds over looping to push payments to many addresses.