-
Notifications
You must be signed in to change notification settings - Fork 160
Assign severity to each sniff #37
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
Conversation
lenaorobei
commented
Feb 11, 2019
- changed rules severities based on [Proposal] Rules Severities for Marketplace Technical Review #14
- changed rules severities based on #14
@@ -235,7 +235,7 @@ class DiscouragedFunctionSniff extends ForbiddenFunctionsSniff | |||
* | |||
* @return void | |||
*/ | |||
protected function addError($phpcsFile, $stackPtr, $function, $pattern = null) | |||
protected function addError($phpcsFile, $stackPtr, $function, $pattern=null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where such spaces removal around =
comes from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. I missed that part of PSR2 standard. Will fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed some rules to be compatible with PSR2.
Anyway, severities are all about Marketplace checks so you don't have to worry about Magento core. For core all findings will lead to build failure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lenaorobei I wouldn't worry about Magento core is there was a separate Marketplace coding standard based on core one. What is the reason to mix such totally different concerns?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@orlangur why do you think so? Extension developers should follow the same rules as core developers.
<type>warning</type> | ||
</rule> | ||
<rule ref="Squiz.PHP.NonExecutableCode"> | ||
<rule ref="PSR2.Methods.FunctionCallSignature"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revising PSR rules severities is not a good idea at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will review this. Thanks for pointing.
Hi @lenaorobei, not sure if it's related to this PR. I always wanted to have Magento codebase following PSR-2 as strictly as possible. Some warnings, like leading underscores, are really hard to fix all over the codebase. Do we have a separate ruleset for new files planned? @paliarush mentioned something like this. In such ruleset we would, for example, convert some warnings to errors just to have new code even cleaner in terms of PSR-2. |
This is definitely what we want to archive and what we are aiming to. The purpose of this coding standard is validation not only Magento codebase but also developers extensions on Marketplace, so we work iteratively in that regard. I reviewed ruleset and made it follow PSR2. I understand that severities do not make sense for core, but we need them for Marketplace technical review. We even have a scoring approach proposal, which should improve the overall code quality of Marketplace extensions. |
- review fixes; - made it follow PSR2;
It means that it should be a separate standard and there is no need to spoil core coding standard :) Of course, we shouldn't have two unrelated standards, like it was with MEQP and core standard, but the standard for Marketplace must be based on core one. Some new rules may be introduced in it which are not applicable to core, some severities adjusted to fulfill needs of Marketplace extension review. But we cannot fulfill contradicting requirements in the scope of a single standard. |
<severity>9</severity> | ||
<type>warning</type> | ||
</rule> | ||
<rule ref="Magento.Security.XssTemplate"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I propose we increase severity here, we should be very strict about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately we cannot restrict this rule right now since its possible issue. We will work iteratively in that regard.
Magento/ruleset.xml
Outdated
</rule> | ||
<rule ref="Magento.Translation.ConstantUsage"> | ||
<rule ref="Generic.Files.ByteOrderMark"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Propose increases severity to 9. We can rename section to "Possible security and issues that may cause bugs".
Magento/ruleset.xml
Outdated
</rule> | ||
<rule ref="Magento.Strings.ExecutableRegEx"> | ||
<severity>10</severity> | ||
<rule ref="Squiz.PHP.NonExecutableCode"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Propose to increase severity to 9.
Magento/ruleset.xml
Outdated
<severity>7</severity> | ||
<type>warning</type> | ||
</rule> | ||
<rule ref="Magento.PHP.DiscouragedFunction"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per our discussion, let's increase severity to 9 because it checks for functions that may lead to security issues.
Magento/ruleset.xml
Outdated
<rule ref="Magento.NamingConvention.ReservedWords"> | ||
<severity>10</severity> | ||
<severity>8</severity> | ||
<type>warning</type> | ||
</rule> | ||
<rule ref="Magento.PHP.DateTime"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Propose increase severity to 9 as it may cause bugs.
Magento/ruleset.xml
Outdated
</rule> | ||
|
||
<!-- Severity 9 warnings: Possible security issues. --> | ||
<rule ref="Magento.Security.IncludeFile"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Propose increase severity to 9 as it may cause security issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume you mean "increase to 10". Done.
@melnikovi changed to proposed severities. Updated WIKI page as well. |
<type>error</type> | ||
</rule> | ||
|
||
<!-- Severity 9 warnings: Possible security and issues that may cause bugs. --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How will this work with PhpStorm? I thought we are going to split the rules with different severity into different rulesets
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PHPStorm will show all issues regardless of severities. I didn't get what you mean here.
split the rules with different severity into different rulesets
Severities are for Marketplace technical review only. What is the purpose of splitting into different rulesets here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we expect to see all issues with any severity highlighted by PhpStorm? Also, this ruleset will be used for Magento core, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we expect to see all issues.
Yes, this ruleset will be used for Magento core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we agreed to move out potentially false-positive rules to separate ruleset to be used with incremental checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now all checks are used with incremental approach. The same behaviour will preserved for the first release. We can discuss false-positive rulesets for future improvements.
@@ -305,6 +306,7 @@ | |||
<rule ref="PSR2.Classes.PropertyDeclaration"> | |||
<severity>6</severity> | |||
<type>warning</type> | |||
<exclude name="PSR2.Classes.PropertyDeclaration.Underscore"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are these excluded? We do not want any variables and method with underscore prefixes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's because a lot of legacy code in Magento. When extension developers extend some classes they need to suppress such findings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need some strategy for the new code to enable such rules there.