Skip to content
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

feat: generated impacts as a part of rule descriptions #898

Merged
merged 8 commits into from
May 25, 2018

Conversation

jeeyyy
Copy link
Contributor

@jeeyyy jeeyyy commented May 16, 2018

PR Checklist

Please check if your PR fulfills the following requirements:

Description of the changes

  • As a part of the documentation for rule descriptions, an additional column describing the impact/ severity of each rule has been added.

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

@WilcoFiers - can you point me to the issue for the same?

@CLAassistant
Copy link

CLAassistant commented May 16, 2018

CLA assistant check
All committers have signed the CLA.

@jeeyyy jeeyyy requested a review from WilcoFiers May 16, 2018 07:48
@jeeyyy jeeyyy requested review from marcysutton and isner May 17, 2018 10:55
@jeeyyy
Copy link
Contributor Author

jeeyyy commented May 21, 2018

@WilcoFiers - review please. Amendment as requested in place.

}

var cumulativeScores = getUniqueArr(
getScore(rule.any, true) // Any: get highest impact
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some squirrely comment spacing here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

refactored so no more beautiful :shipit:

Copy link
Contributor

@isner isner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, Jey.

var id = typeof check === 'string' ? check : check.id;
var definition = clone(findCheck(checks, id));
if (!definition) {
grunt.log.error('check ' + id + ' not found');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we stop execution and return here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure, not a blocker so leaving as is, until I read up grunt docs.

Copy link
Contributor

@WilcoFiers WilcoFiers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No objections, just a topic of worth discussing

function parseImpactForRule(rule) {


function capitalize(s) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm finding it difficult to review code that has nested functions like this. Github won't let me collapse this so I can't simply skip over them when reviewing the outer-most function. The point of abstracting is to let me skip over some of the details, but this way I have to consider multiple scopes when reading through this. I find this is harder to read than it even would have been if the abstractions weren't put in here at all. I'd much prefer that any function that can be moved to the top of the file be moved there.

@isner @stephendonner WDYT? Is that just me?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I agree, this seems to be the existing code-style. We tend to nest function declarations a lot.

Don't think this should necessarily be a blocker, but maybe others feel differently. ¯_(ツ)_/¯

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ignoring above for now, until we reach a consensus...

getScore(rule.any, true) // Any: get highest impact
.concat(getScore(rule.all, false)) // All: get all unique
.concat(getScore(rule.none, false)) // None: get all unique
).sort().reverse(); //order highest to lowest
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would think lowest to highest. Not a big deal though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorted - lowest to highest...

var scores = getImpactScores(checkCollection);
if(scores && scores.length) {
return onlyHighestScore
? [Math.max.apply(null, scores)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might read better as:

[Math.max(...scores)]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is not es6 friendly, leaving it as is...

@jeeyyy jeeyyy merged commit 6265608 into develop May 25, 2018
@jeeyyy jeeyyy deleted the update-impact-for-checks-rules branch May 25, 2018 14:29
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