Coding Style

Coding style is the set of rules a team follows so PHP code looks consistent across the project. It covers indentation, spacing, brace placement, naming, line breaks, file layout, and small readability choices.

Style is not about making code decorative. It reduces friction. When every file follows the same shape, reviewers can focus on behaviour instead of arguing about where braces go or why one file is much harder to scan than another.

Why style matters

In a job, most PHP work happens inside existing code. You read a file, understand the pattern, make a change, and leave the file readable for the next person. Consistent style makes that loop faster.

Poor style creates avoidable cost:

• diffs become noisy
• bugs hide inside cramped code
• reviews drift into formatting comments
• new developers struggle to see the real logic
• automated tools have less predictable code to work with

A junior developer does not need to invent a personal style. The professional habit is to follow the project style already in front of you.

Compare cramped and readable code

This code works, but it is harder to scan than it needs to be.

<?php

declare(strict_types=1);

function total($items){$t=0;foreach($items as $item){if($item['active']){$t+=$item['price'];}}return $t;}

The same logic is easier to review when spacing, names, and line breaks make the structure visible.

<?php

declare(strict_types=1);

function activeProductTotal(array $products): int
{
    $total = 0;

    foreach ($products as $product) {
        if ($product['active']) {
            $total += $product['price'];
        }
    }

    return $total;
}

The second version is not only prettier. It communicates the function's intent, the loop, the condition, and the return value more clearly.

Naming is part of style

Names should explain the role of a value. Short names are fine for very small local ideas, but unclear names make business code harder to maintain.

<?php

declare(strict_types=1);

$p = 1299;
$q = 3;
$t = $p * $q;

echo $t;

// Prints:
// 3897

That code is valid PHP, but it makes the reader guess what the values mean.

<?php

declare(strict_types=1);

$unitPrice = 1299;
$quantity = 3;
$lineTotal = $unitPrice * $quantity;

echo $lineTotal;

// Prints:
// 3897

Clear names reduce mental effort. In real projects, that matters more than saving a few characters.

Keep one idea per line

Dense code often hides important checks. Prefer a shape that lets each decision stand on its own.

<?php

declare(strict_types=1);

function canShip(array $order): bool
{
    if (($order['paid'] ?? false) !== true) {
        return false;
    }

    if (($order['status'] ?? '') !== 'ready') {
        return false;
    }

    return true;
}

This style makes failure rules obvious. It also makes future changes safer because each condition can be edited without unpacking a long expression.

Formatting helps diffs

Readable formatting makes Git diffs easier to review. If a change adds one item to an array, the diff should show one meaningful line instead of rewriting the whole array.

<?php

declare(strict_types=1);

$allowedStatuses = [
    'draft',
    'paid',
    'shipped',
];

Putting each value on its own line is useful when lists are likely to grow. The next change is small and clear.

Do not mix style changes with behaviour changes

A common junior mistake is reformatting a whole file while also changing behaviour. That makes review harder because the reviewer has to separate formatting noise from real logic changes.

When possible, keep style-only changes separate from feature or bug-fix changes. If a file needs formatting before a small bug fix, say so clearly in the pull request.

Manual style habits

Tools will appear later in this track, but you should still learn the habits behind them:

• indent nested code consistently
• use blank lines to separate steps
• choose names that explain intent
• keep functions short enough to scan
• avoid clever one-liners when a simple block is clearer
• match the surrounding project style

What a good style review looks for

When reviewing PHP code for style, ask whether another developer can quickly see the inputs, decisions, outputs, and failure paths. Style should support understanding. It should not become a substitute for correct behaviour.

Before moving on, make sure you can take a cramped PHP function and improve its readability without changing what it does.