code quality and tooling

PSR-1

PSR-1 is a basic coding standard for PHP. It gives projects a shared baseline for file tags, character encoding, file responsibilities, namespaces, class names, constants, properties, and method names.

You do not need to memorise every standards document on day one. You do need to understand the shape PSR-1 expects, because many PHP projects, frameworks, linters, and review comments assume it.

Use normal PHP tags

PHP files should use <?php for PHP code. Short echo syntax <?= is also allowed for output templates, but this track mostly uses full PHP scripts.

PHP example

<?php

declare(strict_types=1);

echo 'Hello from PHP';

// Prints:
// Hello from PHP

Avoid old short open tags like <? because they depend on configuration and are not portable across projects.

Use UTF-8 without a BOM

PHP source files should be saved as UTF-8 without a byte order mark. You usually do this through the editor settings rather than writing code.

The practical reason is simple: invisible bytes before <?php can cause output to be sent before headers, break downloads, or create confusing whitespace in responses.

Do not mix declarations with side effects

PSR-1 says a file should either declare symbols or cause side effects, but should not do both.

A declaration file defines classes, functions, constants, or similar reusable code. It should not also print output or run a database query just because it was loaded.

PHP example

<?php

declare(strict_types=1);

function formatMoney(int $pennies): string
{
    return 'GBP ' . number_format($pennies / 100, 2);
}

That file declares a function. Loading it should not surprise the program by printing text.

A side-effect file is different. A command-line entry script is expected to do work.

PHP example

<?php

declare(strict_types=1);

require_once __DIR__ . '/functions.php';

echo formatMoney(499);

// Prints:
// GBP 4.99

This distinction matters because PHP files are often loaded by Composer autoloaders, test runners, frameworks, or other scripts. A file that secretly performs work when loaded is harder to reason about.

Use namespaces and class names consistently

PSR-1 expects namespaces and classes to follow an autoloading-friendly style. Class names should use StudlyCaps.

PHP example

<?php

declare(strict_types=1);

namespace App\Reporting;

class PriceReport
{
}

PriceReport is clearer than price_report, priceReport, or PRICE_REPORT for a class name.

Constants use uppercase names

Class constants should use uppercase letters with underscores between words.

PHP example

<?php

declare(strict_types=1);

class OrderStatus
{
    public const READY_TO_SHIP = 'ready_to_ship';
}

echo OrderStatus::READY_TO_SHIP;

// Prints:
// ready_to_ship

The constant name describes the PHP symbol. The value can still be whatever string the application needs.

Methods use camelCase

Method names should use camelCase.

PHP example

<?php

declare(strict_types=1);

class ReceiptFormatter
{
    public function formatLine(string $name, int $price): string
    {
        return $name . ': GBP ' . number_format($price / 100, 2);
    }
}

$formatter = new ReceiptFormatter();

echo $formatter->formatLine('Notebook', 499);

// Prints:
// Notebook: GBP 4.99

The class uses StudlyCaps. The method uses camelCase. That difference is intentional and common across PHP projects.

Properties are project-specific

PSR-1 deliberately avoids forcing one property naming style. Many teams still use camelCase for properties because it matches method style.

PHP example

<?php

declare(strict_types=1);

class Product
{
    public string $displayName = 'Notebook';
}

When the standard leaves a choice open, follow the project convention already in the codebase.

What PSR-1 gives you

PSR-1 is not enough to format a whole project by itself. It is a baseline. Later lessons cover PSR-12, formatters, PHP_CodeSniffer, and PHP-CS-Fixer, which enforce more detailed layout rules.

For now, remember the professional habits:

use <?php
keep source files UTF-8 without BOM
separate declaration files from side-effect scripts
use StudlyCaps for class names
use uppercase names for constants
use camelCase for methods
follow the surrounding project when PSR-1 leaves a choice open

Before moving on, make sure you can look at a small PHP file and identify whether it follows the basic PSR-1 expectations.

Practice

Task: Apply PSR-1 Naming

Rewrite this PHP code so it follows the basic PSR-1 expectations covered in the lesson.

PHP example

<?php

declare(strict_types=1);

class receipt_formatter
{
    public const default_currency = 'GBP';

    public function format_line(string $name, int $price): string
    {
        return $name . ': ' . self::default_currency . ' ' . number_format($price / 100, 2);
    }
}

$formatter = new receipt_formatter();

echo $formatter->format_line('Notebook', 499);

// Prints:
// Notebook: GBP 4.99

Requirements

Rename the class using StudlyCaps.
Rename the constant using uppercase words with underscores.
Rename the method using camelCase.
Keep the output the same.
Keep the file as valid PHP.

Show solution

PHP example

<?php

declare(strict_types=1);

class ReceiptFormatter
{
    public const DEFAULT_CURRENCY = 'GBP';

    public function formatLine(string $name, int $price): string
    {
        return $name . ': ' . self::DEFAULT_CURRENCY . ' ' . number_format($price / 100, 2);
    }
}

$formatter = new ReceiptFormatter();

echo $formatter->formatLine('Notebook', 499);

// Prints:
// Notebook: GBP 4.99

The behaviour has not changed. The PHP symbols now follow the expected PSR-1 naming shapes: class names use StudlyCaps, constants use uppercase names, and methods use camelCase.