Description
Repost from squizlabs/PHP_CodeSniffer#2760:
Use-case: sniffs in generic sniff collections - like the
Generic
set in PHPCS - can be freely used by other standards, but shouldn't ever be included in a custom ruleset like<rule ref="Generic"/>
as they may (and often will, likeGeneric
) contain sniffs which contradict each other.For the build-in
Generic
standard, PHPCS makes a hard-coded exception and doesn't list it when someone calls upphpcs -i
.I'd like to propose making that a feature available to external standards as well.
For one, I imagine theSlevomatCodingStandard
could use it, but I see some more use-cases in the future.I envision this can most easily be done by adding a new attribute to the
ruleset
element in thexsd
and adjusting the code for the-i
option to respect the setting found there.Something like
list
with the default beingtrue
.<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Generic" list="false" xsi:noNamespaceSchemaLocation="../../../phpcs.xsd">Implementation-wise, AFAICS this will be easiest to implement via the
Standards::getInstalledStandardDetails()
method and theStandards::getInstalledStandards()
should then probably defer to that method instead of it being a stand-alone method.Opinions ?
Thinking about this issue now, I have a feeling end-users might get confused if they don't see an expected standard when running
phpcs -i
, so hiding the standard(s) may not be the right action.Possibly listing them as a separate category "Additional non-standard rulesets" or something like that ? (including
Generic
)
Or listing them with an*
next to their name or something, might be better.I'd love to see more input from end-users about what would be most helpful to them.