Milestone: Control Flow

This milestone combines the language features from the previous lessons. The goal is not to introduce another syntax feature. It is to prove that you can divide a small workflow into understandable rules, trace every path, and preserve clear ownership of state.

The example processes order records. Each order must have a usable ID, be paid, and have a positive total before it can move to shipping. Rejected orders receive a specific reason, and the script prints a final summary.

Define The Policy Before Writing The Loop

Write the rules in plain language first:

1. a missing or non-positive ID means the record is invalid;
2. only the exact status paid can ship;
3. a missing, zero, or negative total cannot ship;
4. every order produces one result line;
5. shipped and skipped counts must equal the number of processed orders.

These rules define fallback behavior for missing keys. The script does not pretend missing data is valid, and it does not rely on warnings to choose a path.

Give Repeated Questions Names

Small boolean functions make each rule inspectable:

<?php

function hasValidOrderId(array $order): bool
{
    return ($order['id'] ?? 0) > 0;
}

function isPaidOrder(array $order): bool
{
    return ($order['status'] ?? '') === 'paid';
}

function hasPositiveTotal(array $order): bool
{
    return ($order['total_cents'] ?? 0) > 0;
}

Each function answers one question and returns a boolean. The ?? fallbacks are deliberate policy:

• a missing ID becomes 0, which is invalid;
• a missing status becomes an empty string, which is not paid;
• a missing total becomes 0, which is not positive.

A fallback prevents an undefined-key warning, but it does not make incomplete data acceptable. It translates missing data into the rule's rejected state.

Keep Status Mapping Separate

A separate function maps exact status values to review messages:

<?php

function statusMessage(string $status): string
{
    return match ($status) {
        'paid' => 'Ready to ship',
        'pending' => 'Waiting for payment',
        'failed' => 'Payment failed',
        'cancelled' => 'Order cancelled',
        default => 'Unknown status',
    };
}

match is appropriate because one exact string maps to one returned string. The default arm makes the function exhaustive for unexpected values such as refunded or a spelling mistake.

This function describes a status. It does not decide whether an entire order is valid, mutate counters, or print output. Keeping those responsibilities separate makes each rule easier to test.

Process Every Order Through Ordered Guards

Now combine the functions in one loop:

<?php

$orders = [
    ['id' => 701, 'status' => 'paid', 'total_cents' => 2500],
    ['id' => 702, 'status' => 'pending', 'total_cents' => 1800],
    ['id' => 703, 'status' => 'paid', 'total_cents' => 0],
    ['status' => 'paid', 'total_cents' => 900],
    ['id' => 705, 'status' => 'refunded', 'total_cents' => 1200],
];

$shippedCount = 0;
$skippedCount = 0;

foreach ($orders as $order) {
    if (!hasValidOrderId($order)) {
        $skippedCount++;
        echo "Skip record: invalid order ID\n";
        continue;
    }

    $orderId = $order['id'];

    if (!isPaidOrder($order)) {
        $skippedCount++;
        $status = $order['status'] ?? '';
        $message = statusMessage($status);
        echo "Skip order $orderId: $message\n";
        continue;
    }

    if (!hasPositiveTotal($order)) {
        $skippedCount++;
        echo "Skip order $orderId: total must be positive\n";
        continue;
    }

    $shippedCount++;
    echo "Ship order $orderId\n";
}

echo "Shipped: $shippedCount\n";
echo "Skipped: $skippedCount\n";

Output:

Ship order 701
Skip order 702: Waiting for payment
Skip order 703: total must be positive
Skip record: invalid order ID
Skip order 705: Unknown status
Shipped: 1
Skipped: 4

The guards are ordered deliberately. The script validates the ID before reading it into $orderId. It checks payment before checking the total because an unpaid order already has a clear reason not to ship. Each rejected path increments one counter, prints one reason, and uses continue to prevent later checks from running for that order.

Trace One Record At A Time

Do not try to understand the entire loop at once. Trace each record through the same questions:

"Not checked" is meaningful. Once a guard uses continue, execution moves to the next order. A later condition cannot affect the current record.

This trace also proves the counters. One record ships and four records skip, so 1 + 4 equals the five input records. If those totals do not balance, a path probably increments twice or not at all.

Understand Which Scope Owns Each Value

The workflow uses several state lifetimes:

• $orders, $shippedCount, and $skippedCount belong to the top-level script;
• $order is the current loop value in that same top-level scope;
• $orderId, $status, and $message are temporary names used during an iteration;
• each helper function has its own local $order parameter;
• no helper reads or changes the top-level counters.

The counters stay in the loop because the loop owns the processing summary. The boolean functions remain predictable because their answer depends only on the order argument.

Do not move $skippedCount into a hidden global merely so a helper can increment it. That would mix answering a question with changing workflow state. Let the helper return an answer and let the caller decide what that answer means.

Avoid Clever Combined Conditions Too Early

This condition is compact:

foreach ($orders as $order) {
    if (!isPaidOrder($order) || !hasPositiveTotal($order)) {
        continue;
    }

    echo "Process order {$order['id']}\n";
}

It is suitable when every failed condition has the same outcome. It is less useful when the script must print a specific rejection reason, count different categories, or validate one field before safely reading another.

Separate guards are longer but preserve information about the failed rule. Prefer clarity of behavior over minimum line count.

Check Boundary Values Deliberately

A positive-total rule has three important nearby values:

var_dump(hasPositiveTotal(['total_cents' => -1]));
var_dump(hasPositiveTotal(['total_cents' => 0]));
var_dump(hasPositiveTotal(['total_cents' => 1]));

Expected output:

bool(false)
bool(false)
bool(true)

These checks prove that > 0 matches the stated policy. Testing only 2500 would not distinguish > 0 from >= 0.

Status checks also need exact alternatives: paid should pass, while pending, PAID, an empty string, and a missing key should not. Strict comparison makes that policy visible.

Normal Rejection Is Still Control Flow

In this workflow, pending payment, a missing ID, and a non-positive total are represented as normal rejected paths. The script can describe each result and continue processing later records.

The next lesson introduces PHP errors and exceptions for failures that cannot continue normally. Do not add exception syntax to this milestone before learning how throwing, catching, and exception boundaries work. Here, explicit return values and branches are enough to model every expected outcome.

Review Checklist

Before considering a workflow complete, check:

• every array key is read only after a fallback or validity check;
• exact status values use strict comparison;
• each helper function answers one named question;
• helpers receive required data through parameters;
• no helper mutates hidden global counters;
• each order reaches exactly one final outcome;
• every continue intentionally skips all later statements in the loop;
• boundary values around zero are tested;
• unknown statuses have a deliberate fallback;
• summary counts reconcile with the number of input records.

Common Integration Mistakes

What This Milestone Proves

You are ready to continue when you can define the policy before coding, extract boolean rules into small functions, choose deliberate missing-key fallbacks, map exact values with match, order loop guards safely, trace which conditions are skipped, keep counters in the scope that owns them, test boundary values, and reconcile every input record with one output result.

Being able to explain why each record follows its path matters more than memorising the final output. The explanation is the real milestone. The exercises isolate three parts of this workflow: validating orders, predicting a missing-key fallback, and building an exhaustive status router.