-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[3.0.0] Sniff wish list #303
Comments
During the hackathon, the suggestion was raised by multiple people to rename the "integration-tests" directories to something more representative of what's inside. I fully concur and propose to call those "wp-unit-tests". |
I'm going to leave this ticket open for now and move it out of the 3.0 milestone. A significant number of the action items here have been actioned and can be considered fixed with the release of YoastCS 3.0. However, there is still more to be done and this ticket contains lots of information about future scope action items too. |
@diedexx, @enricobattocchi and me have had a brainstorm session in the office this week to validate previously made decisions about code style and best practices and to come up with a list of things we'd like to start enforcing now support for PHP < 7.2 has been dropped in the plugins.
The below is (very long) list of things which were approved during this meeting.
Not everything is "sniffable" and even when it is, some things require new sniffs to be written, so it may be (quite) a while before everything in this list has been actioned.
All in all, this ticket is a mix of an action list and a way to keep track of the decisions taken, even if not all of those can be enforced yet.
Planning
Work on YoastCS 3.0.0 will start after WordPressCS 3.0.0 has been released.
Those action items which can be actioned straight away will be included in YoastCS 3.0.0.
Everything else can be included in YoastCS 3.0.0 if available by then, or in later releases when prerequisites have been fulfilled.
Also see the older YoastCS 3.0.0 roadmap ticket.
Impact
A reasonable number of new rules are in the background already being enforced. For others, a significant amount of work will need to be done to clean up the code bases to comply.
We are fully aware of this and this work will be done over time.
The Free, Premium, Local and Video plugins currently already use a threshold mechanism and those threshold will initially be raised to allow for the new violations until they have been fixed up.
For the other plugins, it will be decided on a case by case basis whether they will be cleaned up in one go or whether the threshold mechanism will be added to these for the time being.
The list
Names in square brackets after a rule indicate the package a sniff exist in or should be added to.
No action needed
The following looks to already been included in WPCS since a long time:
The following looks to have already been activated in YoastCS 2.2.0:
Sniffs covering the below rules have been included in WPCS 3.0 (and this wasn't necessarily clear yet at the time this list was made).
dirname()
function calls, use the$levels
parameter instead. [PHPCSExtra]self::
overClassname::
. [PHPCS]Non-sniff actions needed
Rules for which sniffs are already available and which will be included in YoastCS 3.0
use
statements for classes from the same namespace. [Slevomat]use
statements for classes which are only used in docblocks. [Slevomat] Add a sniff to force types in comments to use use statements. #201use
statements. [Slevomat]use
statements should be ordered alphabetically (per group). [Slevomat] Add a sniff to enforce use statements are in alphabetic order (per group) #213use
statements. [Slevomat]Enforceable via disallowing
use function
anduse constant
statements. [PHPCSExtra] Add sniff to disallow import use statements for functions/constants in the global namespace #214 / Add sniff to enforce importing a namespace not a namespaced function/constant #215The order should be:
use
statementsInitial auto-fix everything to
public
.self::class
,Name::class
combined withuse
statements instead of string names. [Slevomat, move to PHPCSExtra when that version is available]and
andor
operators (without exceptions). [PHPCSExtra]!!
. [PHPCSExtra 1.2.0]null
default value or wherenull
is mentioned as one of the allowed types in the docblock. [??]Note: The sniff needs a bug fix to take
global
statements into account.Select directories, like the
views
directory, may need to be excluded.@param type $var Description
to be aligned across lines. [PHPCS]This will likely give some issues with WP array format annotations, but those aren't used that frequently in the Yoast codebases.
null
should always be listed last, i.e.typeA|typeB|null
. [?]mixed
as data type, except in the test suites. [Slevomat] - Add a sniff to disallow@return
typemixed
in docs #196array
types. These should be made more specific. [Slevomat]abstract
(TestCase) orfinal
(Tests/fixtures). [PHPCSExtra]Rules for which a sniff would need to be written
empty()
. [PHPCSExtra]Future scope: allow it only when combined in the same condition with an
is_array()
check or if applied to a variable which was received as a function parameter with anarray
type declaration and the variable hasn't been touched between receiving it and the call toempty()
.use
statements. [WebImpress/PHPCSExtra ?]void
ornever
return type. [PHPCSExtra]There may be a sniff for this already, needs checking.
Throwable
/Exception
/Error
in catch statements. [PHPCSExtra]Prefer more specific over less specific. They are allowed to be used, but only as a secondary separate
catch
statement, not as the primarycatch
, nor in multi-catch statements.There may be a sniff for this already, needs checking.
Throwable
/Exception
/Error
in type declarations when referring to exceptions. [PHPCSExtra]@inheritDoc
. [?]strict_types
in test files. [PHPCSExtra]data
orprovide
. [PHPUnitQA]abstract
and the class name must be suffixed withTestCase
. [PHPUnitQA]Note: the class name should not be prefixed with
Abstract
.static
(for compatibility with PHPUnit 10). [PHPUnitQA]Rules which cannot be enforced via sniffs in the near future (or ever), but which have manual tasks attached which should be actioned
@api
or@internal
to indicate whether they are part of the public API or not. [YoastCS]A
@since
tag should be added indicating in which version the designation was added, i.e.@since 20.2.1 This class is now internal.
Everything in test directories should be explicitly excluded from this rule.
Follow up plan:
@api
or@internal
, blogposts/release notes/changelogs should start drawing attention to this and announce that use of anything@internal
from outside the plugin is now deprecated.@internal
, like adding return type declarations in non-private
methods and addingstrict-types
declarations.Examples:
ClassUnderTestTest
....\ClassUnderTest
namespace and the test class should be calledMethodUnderTestTest
.@param
for their arguments instead of@api
. [WPCS]For now a one-time search & replace should fix any remaining instances.
Note: Once done, PSR4 should also be used for the autoloading
Rules which need further investigation
@var
docblocks, but require assertions -assert()
statements - instead. [Slevomat]zend.assertions
not set to-1
.public
-protected
-private
.This could possibly be checked by adding metric to the Slevomat sniff ?
The text was updated successfully, but these errors were encountered: