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.
// 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
uncheckedonly for counters proven safe. - Prefer letting users withdraw their own funds over looping to push payments to many addresses.
Practice what you learned
1. Why does `if (balance)` fail to compile in Solidity when balance is a uint256?
2. What is the main danger of looping over a dynamically sized, user-controlled array to send payments?
3. Which optimization reduces gas when a loop repeatedly updates the same storage variable?
4. In Solidity 0.8+, what happens when a loop counter of type uint8 increments past 255 without an unchecked block?
5. What does `continue` do inside a Solidity for loop?
Was this page helpful?
You May Also Like
Functions and Visibility Modifiers
Understand how Solidity functions are declared and the four visibility levels — public, external, internal, and private — plus state mutability keywords like view and pure.
Error Handling with require, revert, assert
Solidity handles errors by reverting state changes. Learn when to use require for input validation, revert with custom errors for gas-efficient failures, and assert for invariants that must never fail.
Function Modifiers in Solidity
Function modifiers are reusable pieces of code that wrap function bodies to enforce preconditions like access control, using the special _ placeholder to mark where the function runs.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics