PHP 7.2 and Modern PHP Habits

PHP 7.2 was released in November 2017. A few months have passed since then, and I’ve started gradually adopting this version in production projects. Looking back, the PHP 7 series has fundamentally changed how I write and think about the language. In this post I’ll briefly touch on what PHP 7.2 brings, and then focus on how the broader idea of “modern PHP” has translated into my everyday habits.

What did PHP 7.2 bring?

The most notable addition in this release is object type hint support. You can now declare a function parameter or return type as object. The scalar type declarations introduced in PHP 7.0 were already a big step forward; object feels like it fills in the missing piece.

<?php

function logObject(object $obj): void
{
    echo get_class($obj) . "\n";
}

This seemingly small addition has a meaningful practical implication: you can now accept a parameter that you know is definitely an object — even without knowing its concrete type — and back it up with a type guarantee.

The other noteworthy change is that objects implementing the Countable interface can now be passed to count(). This is less a new feature and more a consistency fix, but it reflects the general direction: the language wants to behave predictably.

What has changed in daily habits

Since PHP 7.0 there are a handful of habits I’ve adopted and can no longer do without.

Return type declarations top that list. Knowing what a function returns is a big relief for both the person writing and the person reading the code. You can answer the question “can I trust what this method returns?” just by looking at the signature.

<?php

function getUserById(int $id): ?User
{
    return User::find($id);
}

The nullable type syntax ?User arrived with PHP 7.1 and has become one of my most-used constructs. It explicitly tells the caller that the function may return null.

declare(strict_types=1) is another line that now appears at the top of every file I write. With strict types enabled, PHP throws an error instead of silently coercing a wrong-typed value. I initially thought “why would I impose extra rules on myself?” — but I quickly realized that this option catches a surprising number of hidden bugs early.

<?php
declare(strict_types=1);

function multiply(int $a, int $b): int
{
    return $a * $b;
}

multiply('3', 4); // would silently work without strict_types=1; now throws TypeError

Type declarations are a matter of habit

I’ll admit that type declarations feel like overhead at first. When you’re writing a small script, adding a type to every parameter can seem like unnecessary ceremony. But when you look back at your own code in a medium-sized project several months later, those declarations let you understand how a method should be called in a single glance.

Type declarations also boost IDE support. When you use an editor like PhpStorm, it warns you immediately if you pass a value of the wrong type. That tight feedback loop is invaluable for catching mistakes in the editor rather than at runtime.

PSR standards and code style

Following PSR (PHP Standards Recommendations) standards is another pillar of modern PHP habits. I’ve been applying the PSR-2 coding style for several years now; it has become a reflex I follow without having to think about it. Whenever a new person joins a project, or when you need to revisit old code months later, a consistent style delivers unexpected benefits.

Tools like PHP-CS-Fixer or PHP CodeSniffer automate that compliance. Running them before a commit saves you from manually fixing style issues.

Composer and dependency management

The other thing that comes to mind when I hear “modern PHP” is Composer. I’ve been using it since 2014, but my habits around it have matured over time. Every project now starts with a composer.json; I pay close attention to package versions, and I separate development dependencies from production ones using require-dev.

Configuring the autoload section properly matters too. When PSR-4 autoloading is set up correctly, class-not-found errors disappear and code organization becomes much clearer.

The direction of the language

When I moved from PHP 5.6 to PHP 7.0 I felt “this language is changing”; by the time we reach PHP 7.2 I can say “this language is maturing.” Small but meaningful improvements arrive every year, and I see the language becoming more predictable, type-aware, and less “magical.”

I don’t need to rewrite legacy code from scratch to take advantage of new features — I move forward incrementally: adding type declarations to individual functions, enabling strict_types, one step at a time. That gradual migration feels like the pragmatic way to modernize a large project without breaking it.

The start of 2018 is a good time to write type-safe, readable PHP. The tooling is ready, and the ecosystem is moving in that direction.