// Loops & Counting: Tips and Tricks

core idea

Every pattern on this site compiles down to a loop, and interviews are rarely lost on the algorithm idea — they’re lost on the boundary. for vs while, < vs <=, where the middle sits, whether % wrapped the way you assumed: get these automatic and your working memory stays free for the actual problem.

None of this is a pattern by itself. It’s the vocabulary every pattern page on this site assumes you already have — two pointers, sliding window, binary search, and grid BFS all lean on the tricks below without re-explaining them.

when to reach for it

• You’re about to write a loop that must terminate on its own (while, not for) — check that every path through the body actually moves toward the exit condition.
• Two indices converge, chase, or wrap — decide < vs <= before you write the body, not after a bug report.
• You’re computing an index from a formula (mid, n - 1 - i, (i + 1) % n) — plug in the smallest and largest legal input by hand before you trust it.
• A grid problem says “look at the 4 (or 8) neighbors” — reach for direction arrays, not four copy-pasted if blocks.
• You’re about to submit — trace the function on 0, 1, and 2 elements before you trust it on anything bigger.

for vs while

Use for when the iteration count is knowable before the loop starts — you’re walking an array, a fixed range, a known number of levels. Use while when the exit condition can only be evaluated from inside the loop — two pointers converging, a BFS frontier draining, a linked list walk that stops at null. Reaching for for out of habit on a while problem is how people end up hand-rolling a counter they didn’t need; reaching for while on a for problem is how people forget the increment and hang the loop.

public void PrintAll(int[] arr)
{
    for (int i = 0; i < arr.Length; i++)   // the count is known: 0..arr.Length-1
        Console.WriteLine(arr[i]);
}

public int[] TwoSumOppositeEnds(int[] nums, int target)
{
    int left = 0, right = nums.Length - 1;

    while (left < right)                   // the count depends on the data, not the index
    {
        int sum = nums[left] + nums[right];
        if (sum == target) return [left, right];
        if (sum < target) left++; else right--;
    }
    return [];
}

We’ll trace this exact function on 0, 1, and 2 elements further down.

< vs <=: it depends what you’re comparing

There’s no universal rule — the right operator falls out of what “no more work to do” means for that specific loop.

The two binary-search forms aren’t interchangeable — mixing an exact-match update rule into a L < R loop (or vice versa) is exactly how the infinite loop below happens. The full pairing of loop shape to update rule lives on the binary search page; this page only owns the boundary reasoning.

middle element: odd, even, left-mid, right-mid

For a range [L, R] there are two candidate midpoints: floor-mid biases toward L, ceil-mid biases toward R. On an odd-length range they’re the same index — there’s only one middle. On an even-length range they’re neighbors, and which one you pick decides which half of the array a tie lands in.

(int leftMid, int rightMid) Middles(int L, int R)
{
    int leftMid = (L + R) / 2;         // floor — biases toward L
    int rightMid = (L + R + 1) / 2;    // ceil  — biases toward R
    return (leftMid, rightMid);
}

Which one you want depends on the update rule: if a branch sets L = mid, you need rightMid (ceil), or L can get stuck — that’s the whole L = mid bug below. If a branch sets R = mid, leftMid (floor) is safe.

Sometimes the middle never needs a formula at all. Fast/slow pointers finding the middle of a linked list advance fast two steps for every one step of slow; on an odd-length list, slow lands exactly on the single middle node the moment fast.Next is null — no index arithmetic, the geometry does it for you.

ceiling division

Math.Ceiling(a / (double)b) works but drags floating point into a problem that’s entirely integers. The integer idiom is one line and never rounds the wrong way at the boundary:

int CeilDiv(int a, int b) => (a + b - 1) / b;

Note (8, 2) and (7, 2) land on the same answer — 8 divides evenly, 7 rounds up — and CeilDiv gets both right without a special case for the evenly-divisible input. Any “minimum number of X to cover Y” phrasing (minimum days, minimum buckets, minimum speed) is a ceiling-division question wearing a costume — Koko Eating Bananas uses it to bound the search space.

circular indexing and negative modulo

C#’s % is a remainder operator, not a mathematical modulo — the sign of the result follows the dividend, not the divisor. That’s a surprise if you learned modulo from a language that normalizes it (Python’s % always matches the divisor’s sign).

int Mod(int a, int m) => ((a % m) + m) % m;

// -1 % 5 in C# is -1, not 4

Once wrapped through the idiom, the result is always in [0, m) — safe to use as an array index. Apply it directly to circular indexing (rotating array walks, ring buffers, “the element k before this one, wrapping around”):

int Circular(int i, int m) => ((i % m) + m) % m;

buf = [10, 20, 30, 40, 50], m = buf.Length = 5:

i = 5 wraps forward past the end back to index 0; i = -1 wraps backward to the last element. This is the same rule the array toolbox leans on wherever a walk needs to treat the array as a ring instead of a line.

direction arrays

Every grid problem eventually asks “what are this cell’s neighbors?” Four copy-pasted if blocks (if (r > 0) ..., if (r < rows - 1) ..., …) work, but they don’t scale to 8-directional moves and they hide the one piece of logic that actually matters: the bounds check. A pair of parallel arrays turns four blocks into one loop:

int[] dRow = [-1, 1, 0, 0];
int[] dCol = [0, 0, -1, 1];   // up, down, left, right — same order in both arrays

int sum = 0;
for (int d = 0; d < 4; d++)
{
    int nr = row + dRow[d], nc = col + dCol[d];
    if (nr >= 0 && nr < grid.Length && nc >= 0 && nc < grid[0].Length)
        sum += grid[nr][nc];
}

grid = [[1,2,3],[4,5,6],[7,8,9]]. Neighbors of the center cell (1,1) — every direction is in bounds:

sum = 20. Neighbors of the corner cell (0, 0) — two of the four fall outside the grid:

sum = 6. Same loop, no special-cased corner logic — this is the exact mechanic behind Number of Islands and Rotting Oranges.

mirror iteration

Comparing a sequence with itself reversed doesn’t need two separate cursors. One index i climbing from the front is enough — the mirror position is always n - 1 - i.

bool IsPalindrome(string s)
{
    for (int i = 0; i < s.Length / 2; i++)
    {
        int j = s.Length - 1 - i;
        if (s[i] != s[j]) return false;
    }
    return true;
}

IsPalindrome("level") — length 5, so i only runs 0, 1 (s.Length / 2 == 2); the middle character at index 2 is never compared, because it only needs to equal itself:

Loop ends, no mismatch found → true.

IsPalindrome("radar!") — the first comparison already fails:

Returns false immediately — this is the same mirror-inward shape as Valid Palindrome, generalized past skipping non-alphanumeric characters.

the three bug classes

Nearly every loop bug that survives to a bad answer (instead of a compile error) is one of these three.

off-by-one

int[] arr = [10, 20, 30];

// bug: the last valid index is arr.Length - 1, not arr.Length
for (int i = 0; i <= arr.Length; i++)
    Console.WriteLine(arr[i]);

Actual run: prints 10, 20, 30, then throws on the fourth iteration —

10
20
30
IndexOutOfRangeException: Index was outside the bounds of the array.

arr has three elements, valid indices 0, 1, 2; at i = 3 there is no arr[3]. The fix is the for loop from the section above: i < arr.Length, not i <= arr.Length.

the L = mid infinite loop

This is the loop-mechanics bug specific to binary search’s boundary form, and it’s the single most common way a correct-looking binary search hangs.

// buggy — floor mid, and a branch that keeps mid as a candidate
int L = 0, R = a.Length - 1;
while (L < R)
{
    int mid = (L + R) / 2;         // floor mid
    if (a[mid] < 5) L = mid;       // BUG: when R == L + 1, mid == L — L never moves
    else R = mid;
}

Trace on a = [3, 4] (both values are < 5), capped at 6 iterations to prove it never converges on its own:

L and R are identical on every iteration — the real loop never exits. The fix pairs a branch that keeps L as a candidate with ceil-mid, which is exactly the rightMid formula from the middle-element section:

// fixed — ceil mid guarantees mid > L whenever L < R
int L = 0, R = a.Length - 1;
while (L < R)
{
    int mid = (L + R + 1) / 2;     // ceil mid
    if (a[mid] < 5) L = mid;
    else R = mid - 1;
}

Same input, a = [3, 4]:

L == R == 1 after one iteration — loop condition L < R is false, done. The rule: if a branch ever writes L = mid, that loop needs ceil-mid or it can stall exactly when R == L + 1.

negative modulo, reprised

The modulo table above isn’t just a curiosity — it’s the third bug class. Compute a bucket or an array index with a raw a % m where a can be negative (a hash, a “step back from index 0” calculation, a difference of two indices) and C# hands you a negative result. Used as an index, that’s the same IndexOutOfRangeException from the off-by-one bug above, just from the other end of the array. The fix is the one-liner from the circular-indexing section: ((a % m) + m) % m, not a raw %.

the trace-with-0-1-2-elements technique

Before trusting any loop, run it by hand on the smallest inputs that could exist: empty, one element, two elements. Boundary bugs live exactly there — a loop that “obviously” works on a 7-element array can still be wrong about what happens when there’s nothing, or one thing, to compare.

Take TwoSumOppositeEnds from the top of this page:

The empty and single-element cases both terminate without ever entering the loop body — if you’d written while (left <= right) instead, the single-element case would compare nums[0] with itself and could return a false match. Three lines of by-hand tracing catches that before a judge does.