Skip to content

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

Merged
merged 6 commits into from
Feb 28, 2019

Conversation

lenaorobei
Copy link
Contributor

@lenaorobei lenaorobei requested a review from paliarush February 11, 2019 21:51
@magento-cicd2
Copy link

magento-cicd2 commented Feb 11, 2019

CLA assistant check
All committers have signed the CLA.

@lenaorobei lenaorobei changed the title REPO-70: [EQP][Sniffs Consolidation] Assign severity to each sniff Assign severity to each sniff Feb 11, 2019
@@ -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)

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

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?

Copy link
Contributor Author

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">

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.

Copy link
Contributor Author

@lenaorobei lenaorobei Feb 13, 2019

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.

@orlangur
Copy link

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.

@lenaorobei
Copy link
Contributor Author

@orlangur

I always wanted to have Magento codebase following PSR-2 as strictly as possible.

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.

@orlangur
Copy link

@lenaorobei,

severities do not make sense for core, but we need them for Marketplace technical review

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.

@lenaorobei lenaorobei requested a review from melnikovi February 15, 2019 14:27
<severity>9</severity>
<type>warning</type>
</rule>
<rule ref="Magento.Security.XssTemplate">
Copy link
Member

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.

Copy link
Contributor Author

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.

</rule>
<rule ref="Magento.Translation.ConstantUsage">
<rule ref="Generic.Files.ByteOrderMark">
Copy link
Member

@melnikovi melnikovi Feb 15, 2019

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".

</rule>
<rule ref="Magento.Strings.ExecutableRegEx">
<severity>10</severity>
<rule ref="Squiz.PHP.NonExecutableCode">
Copy link
Member

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.

<severity>7</severity>
<type>warning</type>
</rule>
<rule ref="Magento.PHP.DiscouragedFunction">
Copy link
Member

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.

<rule ref="Magento.NamingConvention.ReservedWords">
<severity>10</severity>
<severity>8</severity>
<type>warning</type>
</rule>
<rule ref="Magento.PHP.DateTime">
Copy link
Member

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.

</rule>

<!-- Severity 9 warnings: Possible security issues. -->
<rule ref="Magento.Security.IncludeFile">
Copy link
Member

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.

Copy link
Contributor Author

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.

@lenaorobei
Copy link
Contributor Author

@melnikovi changed to proposed severities.

Updated WIKI page as well.

melnikovi
melnikovi previously approved these changes Feb 15, 2019
<type>error</type>
</rule>

<!-- Severity 9 warnings: Possible security and issues that may cause bugs. -->
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

paliarush
paliarush previously approved these changes Feb 27, 2019
@lenaorobei lenaorobei dismissed stale reviews from paliarush and melnikovi via 9af88d2 February 28, 2019 15:30
@lenaorobei lenaorobei requested a review from paliarush February 28, 2019 15:31
@@ -305,6 +306,7 @@
<rule ref="PSR2.Classes.PropertyDeclaration">
<severity>6</severity>
<type>warning</type>
<exclude name="PSR2.Classes.PropertyDeclaration.Underscore"/>
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@lenaorobei lenaorobei dismissed orlangur’s stale review February 28, 2019 16:34

Not in the roadmap

@lenaorobei lenaorobei merged commit 9706441 into develop Feb 28, 2019
@lenaorobei lenaorobei deleted the REPO-70-Assign-severity-to-each-sniff branch February 28, 2019 20:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants