Defining Functions

function applyDiscount(float $price, int $percent): float
{
    return $price * (1 - $percent / 100);
}

echo applyDiscount(100.0, 25);   // 75.0

Four parts, all of which the next two topics expand: the name, the parameters (each optionally typed), the return type after the colon, and the body. Calling it is just the name and an argument list.

Three semantic rules decide how and when a function exists.

Hoisting. An unconditional top-level function declaration is registered at compile time, so it can be called anywhere in the file — including above its own definition:

echo total([10, 20]);        // works: total is known before this line runs

function total(array $xs): int { return array_sum($xs); }

A conditional declaration — inside if, inside another function — is not hoisted; it only exists once execution reaches it, and calling it early is a fatal Call to undefined function. That asymmetry is why library code declares functions at the top level of each file and lets Composer's autoloader load the file, never wrapping declarations in conditionals.

Scope. A function sees its parameters and its own locals — nothing else. An outer variable is invisible without global, and superglobals ($_GET, $_SESSION) are always available. The design answer is not global but parameters in and values out: a function that takes its dependencies as arguments can be tested with fixtures, while a function that reaches for globals needs a full request to test at all.

Arity. Too few arguments is an ArgumentCountError. Too many is not an error for userland functions — the extras are simply ignored unless the function retrieves them with func_get_args(), a legacy pattern for variadic-style APIs that ...$args replaced.

If conditional declarations are the anti-pattern, there is one legitimate use: polyfills. Guarding a function definition with function_exists lets modern code ship a fallback for older runtimes:

if (!function_exists('str_contains')) {
    function str_contains(string $haystack, string $needle): bool {
        return $needle === '' || strpos($haystack, $needle) !== false;
    }
}

str_contains arrived in PHP 8.0; this shim restores it on 7.4 so the same codebase runs everywhere. Because the declaration is conditional, the guard is mandatory — the function exists only once that line has executed.

Two signature features round out the basics. Pass-by-reference is declared in the signature and lets a function modify the caller's variable — sort($arr) reorders $arr in place, which is why its parameter is array &$array; call-time pass-by-reference (f(&$x)) was removed in PHP 5.4 precisely to keep the effect visible in the signature. And since PHP 8.1, a first-class callable turns any function into a Closure with ellipsis syntax:

$trim = trim(...);                 // a Closure you can pass around
echo array_map($trim, $lines);     // instead of a callback that only wraps trim

Naming is convention, not syntax: ecosystem functions are snake_case (array_merge, htmlspecialchars), and PSR-1 asks the same of plain functions while methods in object-oriented code are camelCase. Whatever the casing, a function name should read as a verb or a verb phrase — sendInvoice, parseLog — because in stack traces and logs the name is the only documentation anyone reads under pressure.

A default value makes a parameter optional at every call site:

function paginate(int $page = 1, int $perPage = 20): array
{
    $offset = ($page - 1) * $perPage;
    return ['limit' => $perPage, 'offset' => $offset];
}

paginate();                // 1 / 20
paginate(4);               // 4 / 20
paginate(4, 50);           // 4 / 50

Optional parameters must be trailing — a required parameter cannot follow an optional one in a sane signature. PHP technically allows function f($a = 1, $b), but then f(5) binds $a and starves $b, and there is no positional way to say "default $a, here is $b". Before 8.0 that was a dead end; named arguments removed it.

Defaults themselves must be constant expressions: literals, constants, consts, and arrays of them — not variables, not function calls. The reason is that a default cannot depend on call-time state; it is part of the function's declaration, evaluated from values the compiler already knows. PHP 8.1 widened this slightly — new PDO(...) and arbitrary constant expressions became legal defaults — but $config['timeout'] never will be.

Named arguments (PHP 8.0) let callers skip parameters and pass by name:

paginate(perPage: 50);              // page defaults to 1
paginate(perPage: 50, page: 3);     // order no longer matters

This is why the "optional before required" smell stopped mattering (f(b: 5) works), and why long parameter lists stopped needing boolean flag arguments. Two costs library authors must weigh: a typo in a parameter name is a runtime Error, not a silent wrong value, and parameter names become part of your public API — renaming one is a breaking change for every caller using names. Variadics cooperate with the feature: function sum(int ...$nums) collects arguments into $nums, and passing named arguments to it gathers the extras into an associative array.

The other half of optional-ness is at the call site: argument unpacking spreads an array into parameters:

$args = [3, 50];
paginate(...$args);

Combined with func_get_args()-style legacy code and ...$named collection, arrays and signatures convert freely in both directions — the same composability the CLI topic relied on for $argv.

Two design consequences are worth stating plainly. First, boolean flag parameters are usually a design smell that defaults plus named arguments have largely retired: createUser('ada', true, false) tells the reader nothing, while createUser('ada', sendWelcome: true, isAdmin: false) does. Second, PHP 8.1's new in initializers lets a default carry an object, which changed how lightweight dependency injection looks:

class Report {
    public function __construct(private Logger $log = new NullLogger()) {}
}

No container, no null checks — callers without a logger still get a working object. The restriction that matters: the default must be a new expression with no arguments spread from variables; anything dynamic still belongs in the body.

Interview framing for this area is usually prediction, not recitation: given a signature with defaults, name the arguments' values after a call mixing positional and named forms. Practice exactly that — positional arguments bind left to right, named ones bind by name, and a second binding of the same parameter is an Error.

The return type is the promise a function makes to every caller:

function invoiceTotal(array $lines): float
{
    $total = 0.0;
    foreach ($lines as $line) {
        $total += $line['qty'] * $line['price'];
    }
    return $total;
}

Without a declaration, callers cannot know — or verify — what they get back. With one, the engine enforces the promise: returning the wrong type raises a TypeError at the return, pointing at the line that broke the contract. Under coercive typing (the default) a : string function that returns 42 yields '42'; under strict_types the same return throws — the coercion-versus-strict split from Variables and Scalar Types applies to returns as much as to arguments.

Three declaration forms cover most code:

function findUser(int $id): ?array    // array OR null — absence is part of the contract
function logout(): void               // returns nothing, ever
function fail(string $msg): never     // never returns normally — it always throws/exits

void means "no value": return; alone is allowed, falling off the end is allowed, and return $x; is a TypeError. The declaration also documents intent for readers — a void function exists to change state, and its result is always null to the caller.

never (PHP 8.1) is the sharper tool: the function always throws or exits, so control flow provably does not continue past the call. It is the right type for a abort() helper or an exception-throwing guard, and static analyzers use it to mark subsequent code unreachable.

The structural habit worth adopting is the guard clause, which keeps the happy path flat:

function findUser(PDO $pdo, int $id): ?array
{
    if ($id <= 0) {
        return null;                                  // early exit, no nesting
    }
    $stmt = $pdo->prepare('SELECT id, name FROM users WHERE id = ?');
    $stmt->execute([$id]);
    $row = $stmt->fetch(PDO::FETCH_ASSOC);

    return $row === false ? null : $row;
}

Compare the alternative — a deeply nested if ($row) { ... } else { ... } — and the trade-off is clear: early returns trade one early exit for an unindented body that reviewers can read in a single pass.

Typed returns also preview the object model: a method may declare : self ("an instance of this class") or, since PHP 8.0, : static ("an instance of whatever class the call started from"). Both appear in fluent APIs, and both interact with inheritance by a rule the engine enforces at compile time — a child class may narrow the return type (parent promises object, child returns User) but never widen it. That covariance rule is how type declarations keep substitution safe without any runtime cost, and it is a reliable follow-up question once you mention return types in an interview.

Two documentation layers finish the story. PHP's own types stop at coarse values: array cannot say which keys and shapes. For that, docblock shapes carry the detail static analyzers consume:

/** @param array<int, array{qty: int, price: float}> $lines */

And naming can encode the contract too: get* and is* promise no side effects, send* and save* promise them. A function whose name, signature, and body all tell the same story is the whole quality bar for this topic.