Variables and Scalar Types

<?php
$user = 'ada';       // string
$user = 42;          // same variable, now an int
$user = [1, 2, 3];   // now an array

PHP variables have no declared type. A $ sigil plus an assignment is the entire declaration ceremony: the variable holds whatever type the last assignment put there, and it changes freely. There is no int x; line, no reservation of memory, no compiler error when a variable changes type mid-function. That flexibility is why a three-line script starts instantly — and why the type of a variable is a property of the program's state, not of its source code, which is exactly what an interviewer will push on: "how do you know what $user holds here?" The honest answer is always "whatever the last assignment gave it — and that is a bug risk you manage with naming discipline and, later, function signatures."

Some rules that shape daily code:

$Count = 1;          // variable names are case-sensitive — $count is a different variable
$_total = 2;         // letters, digits, underscore; cannot start with a digit
unset($user);        // removes the variable entirely
$qty = $_GET['qty'] ?? 1;   // read input safely; see below

Undefined variables. Reading a variable that was never set is a warning in PHP 8 (it was a notice before) that evaluates to null:

Warning: Undefined variable $qty in script.php on line 3

The script continues with null, which is convenient in prototypes and a footgun in production. The ?? operator is the idiomatic guard: $qty = $_GET['qty'] ?? 1; reads "use the request value, else 1" with no warning at all. Chaining works — $a ?? $b ?? 'default' — and ?? specifically skips over null and missing keys without triggering notices, unlike $a ?: $b which also treats '', 0, and false as "empty" (a distinction worth memorizing before the conditionals topic).

Scope. Inside a function, variables are local by default; an outer variable is invisible unless passed in or imported with global $name:

$threshold = 10;
function isAbove(int $v): bool { return $v > $threshold; }  // Warning: Undefined variable $threshold

Passing values as parameters instead of importing globals is the habit that keeps functions testable; global exists mainly for legacy code and the odd bootstrap script.

References. Assignment copies values, except when you ask for an alias with =&:

$a = [1, 2];
$b = &$a;      // $b and $a are two names for the same zval
$b[] = 3;      // $a is now [1, 2, 3]

The same operator in foreach ($rows as &$row) lets you edit elements in place — and produces the classic bug where $row still aliases the last element after the loop, so a later $row = 'x' silently rewrites it. The fix is one line: unset($row); right after the loop ends.

Finally, values you never want to change belong in constants: const MAX_RETRIES = 5; at the top level of a file (compile-time, namespace-aware) or define('APP_ENV', 'prod'); anywhere at runtime. A constant cannot be reassigned, carries a name that explains itself in a stack trace, and — unlike a variable — makes the intent legible to the next reader.

PHP's scalar types are int, float, string, and bool. Each has one or two behaviors that bite in production.

int is platform-sized — 64-bit on essentially every current server, giving ±9.2 quintillion via PHP_INT_MAX. Literals accept decimal, hex (0x2A), and binary (0b101010). When arithmetic overflows the range, PHP silently promotes to float rather than wrapping:

echo PHP_INT_MAX + 1;    // 9.2233720368548E+18 — a float now, precision lost

Money above ~92 quadrillion, or any counter that must be exact, needs an integer string or bcmath.

float is a 64-bit IEEE 754 double (1.5, 1.0e3). Because it cannot represent most decimal fractions exactly, 0.1 + 0.2 === 0.3 is false — compare floats with an epsilon or in cents-as-integers, never with ===.

string is an immutable byte sequence; length is whatever the encoding says, so strlen('café') is 5 on a UTF-8 string, not 4 — the byte-versus-character split returns in the string topic.

bool is true/false, and its trap is PHP's notion of falsy values:

false, 0, 0.0, "", "0", null, []

Everything else is truthy — including the string "false" and the string "0.0", which are non-empty strings and therefore true. So if ($input) on a form field containing "0" silently skips, and the safe test for a user-supplied flag is if ($input === '1') or an explicit allowlist.

Conversions happen in two directions. Explicit casts are written (int), (float), (string), (bool) and follow deterministic rules:

(int) 'apples' → 0 is the one to quote in interviews: it is how a non-numeric product SKU silently becomes "product zero" in a production query.

Inspection tools: gettype($v) returns 'integer', 'string'…, is_int($v) is the precise check, var_dump($v) prints type and value, and is_numeric($v) answers the looser question "could this string be a number?" — useful for validation, wrong for type checks, since is_numeric('42') is true while is_int('42') is false. Numeric strings also carry a subtle edge: since PHP 8, leading whitespace is tolerated (is_numeric(' 42') is true) but trailing junk is not (is_numeric('42 ') is false) — validation code that trims input first is doing real work.

For diagnostics, PHP 8.0 added get_debug_type($v), which returns the actual type name — 'int', 'string', 'null', and for objects the class name ('App\User') instead of gettype's useless 'object':

throw new InvalidArgumentException(
    'Expected int for $id, got ' . get_debug_type($id)
);

And the practical money pattern follows directly from the float caveat: store cents as int (1275), format only at the edge with number_format($cents / 100, 2) — exact arithmetic all the way through, pretty printing exactly once.

By default PHP coerces scalar arguments to match a declared parameter type. Add one declaration and it stops:

<?php declare(strict_types=1);    // must be the FIRST statement in the file

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

discount('19.99', '20');    // TypeError: Argument #1 must be of type float, string given

Without the declaration, that same call silently works: '19.99' becomes 19.99 and '20' becomes 20. Coercion is convenient for form input and catastrophic for real bugs — the typo that passes '19.99' where an id was expected becomes a valid price instead of an immediate failure.

Two facts about strict_types are interview gold:

1. It applies to the file where the call is made, not where the function is defined. If discount() lives in a strict file but you call it from a legacy file without the declaration, coercion still happens for that call. Strictness is a per-call-site switch, which is why a partially migrated codebase behaves inconsistently until every caller opts in.

2. It must be the first statement. Before any code, before any output; anywhere else it is a compile error: strict_types declaration must have 1 as its value covers the malformed forms. It cannot be applied retroactively to a running script.

What strict mode does and does not change:

// Coercive mode (default)
discount('19.99', 20);     // coerced — runs
discount('abc', 20);       // TypeError even here; no leading number to convert
// Strict mode
discount(19.99, '20');     // TypeError: string given, int required

Coercion still throws when conversion is impossible, so strict mode is not about "making errors possible" — it is about making wrong-but-convertible values fail instead of sliding through. The same principle governs returns: a : string function that return 42; yields '42' under coercion and a TypeError under strict. And since PHP 8.0, internal functions follow the same contract — strlen([]) is a TypeError, not a warning and null.

The bool parameter under coercion deserves its own warning, because it converts intent into nonsense:

function notify(bool $immediate = false): void { … }

notify('no');      // coercive: any non-empty string except '0' is TRUE
notify('off');     // also true

The strings 'no' and 'off' are non-empty and not '0', so they coerce to true — the exact opposite of what a caller typing --notify=no meant. This is the strongest argument for keeping boolean parameters internal to well-typed code and parsing string flags into real booleans at the CLI or form boundary, where 'no' can be matched against an allowlist before it ever reaches a signature.

The practical rollout pattern: add declare(strict_types=1); to every new file as line one, and convert existing files one at a time — each conversion is safe because it only tightens that file's call sites, surfacing mismatches exactly where you are already looking. Tools like Rector automate the mechanical part (inserting declarations, fixing flagged call sites), leaving you the interesting work of deciding what each caught mismatch should have meant. The one thing strict mode deliberately does not solve is untrusted input: $_POST['qty'] arrives as a string no matter what your signatures say, so validate and convert at the boundary ((int) ($_POST['qty'] ?? 0)) and let everything downstream stay strict.