phpcsstandards / php_codesniffer Goto Github PK

View Code? Open in Web Editor NEW

844.0 20.0 52.0 203.1 MB

PHP_CodeSniffer tokenizes PHP files and detects violations of a defined set of coding standards.

License: BSD 3-Clause "New" or "Revised" License

JavaScript 1.16% PHP 98.43% CSS 0.38% HTML 0.02% Batchfile 0.01% C++ 0.01%

automation cli coding-standards php phpcbf phpcs psr1 psr12 psr2 qa

php_codesniffer's People

Contributors

Stargazers

Watchers

Forkers

automattic anomiex fredden sc0ttkclark sclark3-godaddy mauriciofauth stronk7 frankdekker benjamin-loison rodrigoprimo przemekhernik lucc dingo-d nadiaglonyagina fcool remicollet mbomb007 jorgsowa move-elevator joachim-n jaymcp githangar cordis-dev cgocast temp shepardo staabm michalbundyra olivervogel connorhu jpoliveira08 kiisterplaster luc45 karthisiv james-cnz collisiondetection klausi costdev gromnan rneufeldcisco asenar digitaltailorke rolandfarkascom creative-emporium veerajongit biinari zezo-ai andypost dingi3 davgit

php_codesniffer's Issues

PSR12.Files.FileHeader: false positive when there is no header

Repost from squizlabs/PHP_CodeSniffer#2997:

Given the following code run against the PSR12 standard:

<?php

/*
 * Not a file docblock.
 */

/**
 * Docblock for an include statement.
 */
include 'foo.php';

I get the following error:

--------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------------
 9 | ERROR | [x] Header blocks must be separated by a single blank line
   |       |     (PSR12.Files.FileHeader.SpacingAfterBlock)

... while I expected none.

See the original thread for additional information.

PHP 8.0 | Tokenizer: Handle reserved keywords being used in namespaced names

Repost from squizlabs/PHP_CodeSniffer#3336:

PR #3063 and it's PHPCS 4.x sister-PR addressed the namespaced name token changes as outlined in #3041.

The underlying PHP RFC, however, contains another change which is so far unaccounted for: reserved keywords can now be used in namespaced names.

The impact of this change is limited to PHP 8.0 code which actually uses reserved keywords in namespaced names, so the fact that PHPCS does not handle this yet, will probably not affect many people for now.

I've been doing some research to see what the impact is of this and have come to the conclusion that we will need to adjust the tokenizer for this in PHPCS 3.x.
With the retokenization to the PHP 8 tokens in PHPCS 4.x, I expect that there will be far less issues in PHPCS 4.x, though a slightly different fix may still be needed there too, but I will check that later just to be sure.

The problem is two-fold:

PHP 8.0

When PHPCS is run on PHP 8.0, single-level namespace names and single-level within a group use statement, are the only ones which will really cause a problem. Note: the below code sample is valid PHP 8.0 code.
namespace Class;

use Foreach;

use Package\{
    Include
};
The examples from the above code sample are likely to also cause issues in PHPCS 4.x, but I expect that those will be the only problem cases in PHPCS 4.x.

Multi-level namespace names are split into T_STRING tokens separated by T_NS_SEPARATOR tokens, independently of the token content, so reserved keywords in multi-level namespaced names are not affected. See PR #3063.

PHP 5.4-7.4

When PHPCS is run on PHP 5.4-7.4 against code written for PHP 8.0, the problem is much more extensive as reserved keywords used in namespaced names will, in that case, always tokenize as their keyword token, which will cause lots of sniffs looking for a particular keyword to throw false positives and will cause at least one sniff to go into an infinite loop (which sniff is still to be identified).
namespace For\Include\Class;

use Goto\Interface;

\Echo\Private\function_name();
Sniffs which are impacted by this.

The below lists are based on an initial scan with some test code against all PHPCS native standards. This type of scan will only show false positives, not false negatives, so in practice, there are likely to be more sniffs affected, but these lists give some indication of the problem.

As some of these sniffs contain auto-fixers, it can be presumed that the result of running phpcbf on PHP 8.0 code using reserved keywords in namespace names will cause the fixers to introduce parse errors into the code.

Also, these lists are limited to the PHPCS native sniffs, while sniffs in external standards will, of course, also be affected.

When running PHPCS on PHP 8.0

Generic.Arrays.DisallowLongArraySyntax

Generic.Classes.OpeningBraceSameLine

Generic.ControlStructures.InlineControlStructure

Generic.Files.OneObjectStructurePerFile

Generic.NamingConventions.InterfaceNameSuffix

Generic.PHP.DiscourageGoto

PEAR.Classes.ClassDeclaration

PEAR.Commenting.ClassComment

PEAR.Commenting.FunctionComment

PEAR.Files.IncludingFile

PEAR.NamingConventions.ValidClassName

PSR2.Classes.ClassDeclaration

PSR2.Namespaces.UseDeclaration

PSR12.Classes.ClassInstantiation

PSR12.Files.DeclareStatement

PSR12.Files.ImportStatement

PSR12.Operators.OperatorSpacing

Squiz.Classes.ValidClassName

Squiz.ControlStructures.ForEachLoopDeclaration

Squiz.ControlStructures.ForLoopDeclaration

Squiz.Files.FileExtension

Squiz.WhiteSpace.ScopeKeywordSpacing

Squiz.ControlStructures.ForEachLoopDeclaration

Squiz.ControlStructures.ForLoopDeclaration

Squiz.Functions.GlobalFunction

Squiz.Operators.ValidLogicalOperators

Squiz.PHP.DisallowBooleanStatement

Squiz.WhiteSpace.LogicalOperatorSpacing

There is also at least one sniff (in the Squiz standard) which causes an Internal.Exception

When running PHPCS on PHP 5.4-7.4

(partial list as the PSR1, PSR2, PSR12 and Squiz standards go into an infinite loop)

Generic.Arrays.DisallowLongArraySyntax

Generic.Classes.OpeningBraceSameLine

Generic.CodeAnalysis.UnconditionalIfStatement

Generic.ControlStructures.InlineControlStructure

Generic.Files.OneObjectStructurePerFile

Generic.Functions.OpeningFunctionBraceBsdAllman

Generic.NamingConventions.CamelCapsFunctionName

Generic.NamingConventions.InterfaceNameSuffix

Generic.NamingConventions.TraitNameSuffix

Generic.PHP.DiscourageGoto

Generic.WhiteSpace.LanguageConstructSpacing

Generic.WhiteSpace.ScopeIndent

PEAR.Classes.ClassDeclaration

PEAR.Commenting.ClassComment

PEAR.Commenting.FunctionComment

PEAR.ControlStructures.ControlSignature

PEAR.Files.IncludingFile

PEAR.Functions.FunctionDeclaration

PEAR.NamingConventions.ValidClassName

PEAR.NamingConventions.ValidFunctionName

PEAR.WhiteSpace.ScopeIndent

PEAR.WhiteSpace.ScopeClosingBrace

Squiz.Functions.GlobalFunction

Proposed fix

I propose to add code to the Tokenizer\PHP class to retokenize reserved keywords used in namespace(d) names to T_STRING.

A similar, but far more limited fix will need to be applied to PHPCS 4.x for single-level namespace name use.

PR #3484 and its follow-ups should have fixed the majority of issues, but it would still be good to verify this.

`// phpcs:set` is not limited to the file in which it is used

Repost from squizlabs/PHP_CodeSniffer#2126:

I may be missing something, but AFAICS and in contrast to the other //phpcs: annotations, using // phpcs:set Standard.Category.Sniff PropertyName value is not file-based, but changes the sniff property for the rest of the PHPCS run.

IMHO this is unreliable as the effect of this depends on:

the order in which the files are sniffed which may change without notice;

will not work as expected when used in combination with the parallel option.

While in practice, this feature is mostly used in PHPCS unit tests, it is a useful feature as there is no other way to set a property for a limited group of files.

Would it be possible to make the effect of the // phpcs:set annotation be file-based ?

I imagine, that this could be done by saving the original value of the property when the first // phpcs:set for a certain property in a file is encountered into an array like $propertyOverrides[$sniffName][$propertyName] = $originalValue; and resetting the property to that original value once the last token of a file has been reached (or something along those lines).

Example use-case:

Say I have a sniff which checks variables in the global namespace or within a function scope when a global statement is encountered.

Now , say a project has view files which are included from within a function in another file. For those files it would be useful to be able to set a property FileType view which would only apply to that file.
That way, for that file, the "global" namespace could be treated as scoped and the sniff would only check the variables and throw errors when a global statement is encountered.

Using phpcs:disable for that file or <exclude-pattern> the file from within a custom ruleset, is not an option as that would disable the sniff completely.

But setting phpcs:set at the top of the file currently changes the behaviour of the sniff for that file and all files scanned after it, which is not the intention either.

See the original discussion for some additional input.

Docs: add more information about `parallel` option

Repost from squizlabs/PHP_CodeSniffer#1732:

I've just been looking into the parallel running option a bit more and am left with some questions.

When should you use this option ?

Does it work equally well with phpcs as well as phpcbf ?

What things should you take into consideration when determining the amount of parallel processes to use ?

What can go wrong ? Are there any type of sniffs which would be incompatible with parallel processing ?

Any thing else which behaves differently if parallel processing is turned on ?

It might be useful to add a section to the Wiki Advanced Usage page about this.

👉🏻 The thread in the original post contains lots of useful comments and would be a good starting point to start writing this up.

QA: standards should not have conflicting rules / fix fixer conflicts

Premise

A standard should be able to be used without leading to fixer conflicts.

Now, as code can be written in lots of different ways, it is not always straight forward to anticipate potential conflicts, however, PHPCS contains a wealth of test code, so by running the fixers for a standard over all test case files, we should be able to detect a lot of potential fixer conflicts.

Current status

While I have the workflow and the set up for this check ready, it cannot currently be turned on as all standards, except PSR1, lead to fixer conflicts.

Note: as CSS/JS support will be dropped in v 4.0, I've not included the CSS/JS test case files in the set up for the fixer conflict check.

Also note that Generic is not a standard but a sniff collection containing conflicting rules by design. For that reason, the fixer conflict check is not relevant.

Last update date for the "current status": 2024-07-29
Please feel free to ping @jrfnl for an update if the list is outdated.

Details of current fixer conflicts for the PEAR standard

Command:

phpcbf -p . --standard=PEAR --ignore=*/build/*,*/vendor/* --basepath=. --extensions=inc --suffix=.conflictcheck