Declare strict types?

[g-elwell]

Hey all.

I'm looking to get a consensus on where people's preferences lie regarding declaring strict types in PHP files, ie:

<?php

declare(strict_types=1);

Is this something we're doing across most projects in Big Bite? If not, should we be? Should we consider adding a sniff to help enforce/guide inclusion of this declaration?

On the other hand, if we're not in a position to add this to our shared PHPCS config, is anyone aware of an existing sniff that could be used at project level should we want to enforce this?

Thanks!

[jaymcp]

Strict typing impacts function calls, not function definitions, so it would primarily impact first party code. This is because WordPress function definitions do not use type hints, so declaring strict types would have no impact if passing ostensibly incorrect parameter types to core functions. Both scenarios should be adequately accounted for by correctly implementing static analysis via PHPStan, since WP code does specify acceptable parameter types in its DocBlocks.

With strict typing enabled, PHP will throw a Fatal TypeError when incorrect parameter types are passed. This is fine during development, but — in my opinion — we would normally prefer to quietly error, rather than terminate execution (in production). It is very possible to break the application completely if all edge cases are not accounted for when handling user data.

Further to this, Fatal Error stack traces have the potential to expose sensitive data if the #[SensitiveParameter] attribute isn't implemented correctly.

---

The Generic standard in PHPCS itself includes a sniff that can enforce the declaration, so we wouldn't necessarily need to write a custom sniff for this:

Generic.PHP.RequireStrictTypes

Nitpick - our coding standards would require the declaration to look like this:

<?php

declare( strict_types = 1 );

[ampersarnie]

in my opinion — we would normally prefer to quietly error, rather than terminate execution (in production).

This is not something, or a stance I've come across before - avoidance in production - when it comes to strict typing. Do you have any prior art or standards that follow this reasoning that we can read on for considering it with our standards?

I know its in our own documentation but it is something I do have issue with because of this same reason.

[jaymcp]

in my opinion — we would normally prefer to quietly error, rather than terminate execution (in production).

This is not something, or a stance I've come across before - avoidance in production - when it comes to strict typing.

I was referring to the preference of avoiding Fatal Errors in production, not specifically by not enabling strict typing; however, enabling strict typing is one means through which one introduces a much more significant probability of causing Fatal Errors in production.
Since strict typing is a binary choice, I would recommend against its usage in any code. Instead, tools like PHPStan should be used to ensure that the code is robust, without introducing the additional risk in production environments.

I know its in our own documentation...

I had hoped that I had caveated the downsides of its usage sufficiently. Should we further clarify in the documentation?