Writing PHP that runs is easy. Writing PHP that a team can still understand, extend, and safely change eight months later is a different skill. This page pulls together habits that don't map to a single feature or syntax rule — they're judgment calls about how you structure code, name things, and organize a project so that it stays maintainable as it grows. None of these are enforced by the PHP interpreter; they're conventions the wider PHP community has converged on because the alternative gets painful at scale.

PSR-12 is a community-maintained coding style standard: four-space indentation, one class per file, braces on their own line for classes and methods, a consistent order for declare, namespace, and use statements, and so on. None of these choices are objectively "better" than reasonable alternatives — the value is in everyone on a team (and across the wider PHP ecosystem) using the same one, so that a file looks the same regardless of who wrote it. Most editors and CI setups can enforce this automatically with a tool like PHP-CS-Fixer or PHP_CodeSniffer, so nobody has to remember the rules by hand.

A variable named $d or a function named process() forces every future reader to open the code and reverse-engineer what it actually does. Names should describe intent: $daysUntilExpiry instead of $d, sendWelcomeEmail() instead of handle(). This costs a few extra seconds while typing and saves minutes (multiplied by every person who reads the code afterward, including you in six months). The same applies to boolean variables and functions — prefixing them with is, has, or should (isActive, hasPermission) makes their meaning obvious at the call site without checking the definition.

By default PHP coerces types where it can — passing the string "5" to a function that types its parameter as int just silently converts it. Adding declare(strict_types=1) at the top of a file disables that coercion for calls made from that file: a type mismatch throws a TypeError immediately instead of being quietly converted, which surfaces bugs at the point they happen rather than several function calls downstream.

A function that validates input, queries the database, formats a response, and sends an email is doing four jobs, which means it has four separate reasons to change and four separate ways to break. Splitting it into four smaller functions — each with one responsibility and a name that says exactly what it does — makes each piece independently readable, independently testable, and reusable somewhere else without dragging the other three responsibilities along with it. The same idea applies to classes: a class that has outgrown its single purpose and started absorbing unrelated behavior is usually a sign it should be split.

Reaching for a global variable, a static property, or a singleton inside a function is convenient in the moment, but it hides a dependency: nothing in the function's signature tells you it relies on that global, so tests have to fight to reset it and other code can change it out from under you. Passing dependencies in explicitly — through a constructor or function parameter — makes every dependency visible at the call site and lets tests substitute a fake version without needing to touch global state at all.

A deep inheritance chain — a class extending a class extending another class — tends to become fragile: changing behavior in a base class can ripple unpredictably through every descendant, and understanding what a leaf class actually does means reading its entire ancestry. Composition (building a class out of smaller collaborator objects passed in through the constructor) and coding against interfaces instead of concrete classes usually age better: each piece is independently replaceable, and a class only depends on the contract it actually needs, not everything a parent class happens to provide.

Composer's version constraints control how much a dependency is allowed to drift when someone runs composer update. A loose constraint like "^2.0" lets any 2.x release in, including one that quietly changes behavior your code relies on. Committing composer.lock ensures everyone on the team, and every deployment, installs the exact versions that were tested together, while an occasional deliberate composer update (reviewed, not automatic) is how you actually move forward.

It's tempting to treat tests as cleanup work done once a feature "works," but by that point you've already lost the moment when you understood the edge cases best. Writing a test right after (or before) writing the function that satisfies it means the edge cases — empty input, a negative number, a missing record — are still fresh in your mind, and the test becomes a safety net for every future change to that function rather than a chore retrofitted months later, if it happens at all.