Drop the leading slash for global native functional calls?

[oliverklee]

Adding a leading slash when calling native global PHP functions like strlen slightly improves performance while also introducing visual noise.

Also, this style is not very well-known and caused confusion for contributors in the past.

The TYPO3 Core does not use this style, and I'm trying to harmonize the setup and style across my projects.

@JakeQZ @sabberworm Would you be okay with us dropping the leading backlash? (I'd then create PRs for both our projects to enforce this using a PHP-CS-Fixer rule.)

[JakeQZ]

I'd prefer to keep the leading backslash. As well as the slight performance benefit, it also makes it clear that a function in the global namespace is being called, not one in the source file's own namespace or some other namespace that is referenced via a use statement. And it means the coding style is consistent with how class names in the global namespace are referenced (e.g. \Exception).

Also, it would not be possible to remove the leading backslash in all cases, for example:

use function Safe\preg_replace_callback;
// ...
if (\function_exists('Safe\\preg_replace_callback')) {
    $normalizedOriginalStyle = preg_replace_callback($pattern, $callback, $node->getAttribute('style'));
} else {
    // @phpstan-ignore-next-line The safe version is only available in "thecodingmachine/safe" for PHP >= 8.1.
    $normalizedOriginalStyle = \preg_replace_callback($pattern, $callback, $node->getAttribute('style'));
    \assert(\is_string($normalizedOriginalStyle));
}

If the leading backslash is dropped (in the else clause), it will result in an error: "Call to undefined function Safe\preg_replace_callback()". Somewhat disappointing, as otherwise we would have been able to remove the if/else altogether (if we were to decide to drop the leading backslash).

[JakeQZ]

PS. I also came across this thread on Reddit which may be food for thought.

[JakeQZ]

PPS.

... also introducing visual noise.

It's only visual noise if you're not used to it.

What about using :: for a static method call? Wouldn't a single : suffice (apart from it not being valid syntax, nor what C++ uses)? It's extra visual noise that we've got used to.

Since MyIntervals/emogrifier#573 (8 years ago), I've got used to it, seen it to be an improvement (for the reasons given above), updated my libraries to use the convention, and now find it somewhat grating to see code calling inbuilt functions without the FQN (leading backslash).

To go back would be (tautologically) a retrograde step I think.

Also, this style is not very well-known

Maybe it should become better-known, and used more. By continuing to use this convention, we may persuade others to adopt it, as they see the light... :)

[JakeQZ]

PPPS.

... and caused confusion for contributors in the past.

I'm struggling to recall such instances. It's possible in review we asked them to add leading backslashes (which I don't think we should).

I don't think we should be too nitpicky in contributor PR reviews. If the proposed changes are of a satisfactory standard, pass the CI checks, and include some tests (if applicable), we should merge, and tidy up the nitpicks ourselves afterwards. If we are too harsh, we will put people off contributing.

[oliverklee]

Okay, some more background on this. 🙂

My personal preference is to always have the leading slash (to make things explicit and for the slight performance improvement).

This is trumped by my desire to keep the setup of my projects consistent (to reduce cognitive load, and to make copy'n'pasting or sharing the setup easier).

This is trumped by my TYPO3 projects following what the TYPO3 Core does (for the same reasons, with the added aspect that there are actually people outside my own little company who both contribute to the TYPO3 Core and my TYPO3 extensions).

This is trumped by technical necessity (in this case, we'll need to keep using the leading backslash at least for the PHP-Safe-provided functions).

This is trumped by us coming to decisions using a consensus (or consent) system in the two MyIntervals packages (i.e., Emogrifier and PHP-CSS-Parser).

So, to boil it down: It looks like we'll keep the leading backlash in the MyIntervals packages, and I'll have to keep this in mind when switching between projects. 🙂

[JakeQZ]

This is trumped by technical necessity (in this case, we'll need to keep using the leading backslash at least for the PHP-Safe-provided functions).

I thought of a couple of ways around this for the 'Safe' functions that may or may not be defined:

• Use use as for them;
• Don't use use and instead call them with FQN.

But neither are ideal, and I prefer to keep the leading backslash anyway for the reasons already given.

[oliverklee]

Oh, and some more background:

I am self-employed as a TYPO3 extension developer and workshop teacher (for TYPO3 development, leadership and team development). I'm a member of the TYPO3 Best Practices Team, where we research, develop and teach best practices for developing high-quality TYPO3 extensions. We try to keep our recommendations close to what the TYPO3 Core does. I also occasionally contribute to the TYPO3 Core, but I'm not a member of the TYPO3 Core mergers (AKA the TYPO3 Core Team), i.e., the group of people who decide things about the TYPO3 Core.