Add autofix support for Squiz.Operators.ValidLogicalOperatorsSniff #613
Conversation
There was a problem hiding this comment.
Hi @Koopzington, thank you for porting this PR over and for your willingness to contribute to PHPCS.
While I like the principle of the change, like Greg before me, I'm hesistant about merging the PR as-is. My hesistation is mostly because, IMO, the tests are not comprehensive enough.
All the test cases use quite simple code samples, while in real world code, things get messy and I don't currently have enough confidence that your changes will hold up in that scenario.
To help find more test cases, I've ran the sniff as per this PR over the top 2000 Packagist packages.
I've posted the results here: https://gist.github.com/jrfnl/ef7144c0d9b6fedf24dcb8f1d62685fe
Note: For this test run, I've changed the error code for the auto-fixable error to allow for seeing how many fixable and non-fixable issues were found. This is not a change which should be applied in the PR.
I'd like to suggest going through those results with a fine toothcomb to a) find any false positives which need to be handled (false positive in the sense of fixable, while it shouldn't be) and b) find test cases which should be added to the sniff tests (in anonymized form).
While doing so, keep in mind that the Packagist top 2000 are generally well-coded packages, so running the sniff over less well-coded packages may provide more useful input, but this is what I had available. Having said that, I would wager you can still find some inspiration in the results for improving the tests.
I've also left some remarks/questions inline with additional feedback.
I look forward to the next iteration of the PR.
P.S.: Mind - you may need to rebase the PR on the current master to get a passing build due to some hickups in the CI which have been fixed in the mean time.
| T_YIELD, | ||
| T_YIELD_FROM, | ||
| T_PRINT, | ||
| ]; |
There was a problem hiding this comment.
Any particular reason not to use the Tokens::$assignmentTokens token array when building this list ?
| $foo = ($a or $b xor $c); | ||
| $foo = ($a and $b or $c); | ||
| print $a and $b; | ||
| yield $a and $b; | ||
| ?> |
There was a problem hiding this comment.
As this is a fixer, which could potentially lead to a change in behaviour in an application, I'd like to see a lot more variation in the tests to verify that the determination whether something is fixable is done correctly.
The fast majority of the above tests are quite simple statements, while real life code gets a lot more complex and varied.
Some examples of syntaxes I'm missing in the tests:
- ternary expressions
- use in an array key
- use in an array value
- use in a match condition
- use in a match return expression
- combinations of multiple operators, think: a ternary with an inline
printexpression
| if ($tokens[$index]['code'] === T_OPEN_PARENTHESIS) { | ||
| $index = ($phpcsFile->findEndOfStatement($index + 1) + 1); | ||
| } |
There was a problem hiding this comment.
Is there any particular reason why findEndOfStatement() is used here instead of skipping to the parentheses closer via the $tokens[$index]['parenthesis_closer'] index (if it exists and if it doesn't exist, that's saying something too) ?
| $index = ($phpcsFile->findEndOfStatement($index + 1) + 1); | ||
| } | ||
|
|
||
| if (in_array($tokens[$index]['code'], $blockList, true) === true) { |
There was a problem hiding this comment.
Performance nitpick: please set up the blocklist to allow for using isset() instead of in_array().
Description
Here's my slightly belated retarget of squizlabs/PHP_CodeSniffer#1370
The changes enable autofixing for cases where code behaviour won't change by replacing
andwith&&as well asorwith||.Suggested changelog entry
Added
Types of changes
PR checklist