Open jrfnl opened 6 years ago
At the same time, I realize this is more of a "best practice" kind of sniff, which is outside of the scope of PHPCompatibility.
You probably know my opinion, as this kind of thing has come up before. 😃
My view is that if it's not a compatibility issue, it doesn't belong in the library.
I think there is probably a good case for a separate PHPOptimisation standard, which could include this kind of sniff and could also advise on other potential performance optimisations, but it seems orthogonal to the aim of PHPCompatibility.
a good case for a separate PHPOptimisation standard, which could include this kind of sniff and could also advise on other potential performance optimisations
Sounds like an interesting project which could be very useful.
This was originally a question @mbabker asked me about PHPCS, it's based on the following issue https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/3048
FYI: A sniff for this - including auto-fixer - will be included in the new PHPModernizer
standard in the foreseeable future.
I'm going to try out the new "transfer issue" functionality and move this issue to the PHPModernizer repo.
From the PHPCS gitter - originally posted by @photodude:
The reason why I think this would be a good addition to PHPCompatibility is that a sniff for this would help people take advantage of a (lesser known) PHP7 feature which would make their code more compatible with PHP7 (while not making it incompatible with lower PHP versions).
A sniff for this could check if the functions are used within a namespace and not prefixed with a
\
nor referenced in ause
statement and throw awarning
iftestVersion
would have a minimum PHP version of PHP 7.0.At the same time, I realize this is more of a "best practice" kind of sniff, which is outside of the scope of PHPCompatibility.
Opinions ?