-
Notifications
You must be signed in to change notification settings - Fork 889
Added unnecessary-else Rule #4502
Added unnecessary-else Rule #4502
Conversation
Thanks for your interest in palantir/tslint, @debsmita1! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request. |
* Added more testcases * Made minor changes to the FAILURE_STRING
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.
Great start! Some architectural changes should be made.
2214c29
to
0f7d798
Compare
I have addressed all your comments. |
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.
Looks close, thanks for the docs & code examples! Just waiting on simplifying the recursive calls and adding handling for non-block if
bodies.
src/rules/unnecessaryElseRule.ts
Outdated
} | ||
ts.forEachChild(node.thenStatement, cb); | ||
} else { | ||
return ts.forEachChild(node, cb); |
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 looks like you have a few different ts.forEachChild
s: individual ones for the node's elseStatement
and thenStatement
if it's an IfStatement
, but just a regular recursion otherwise? You should be able to simplify this a bit by only having one call to ts.forEachChild
that's always called.
Also, if jumpStatement
is undefined but node.elseStatement
isn't, this code will skip it. That seems like a potential bug?
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.
Done be2f8b4
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.
Sorry @debsmita1 I think I wasn't very clear here. I'm suggesting you don't need to have ts.forEachChild
statements in the big if (utils.isIfStatement
block:
if (utils.isIfStatement(node)) {
// all your glorious rule logic here
// no ts.forEachChild in this area
}
ts.forEachChild(node, cb);
Note the lack of else
statement: a single ts.forEachChild
should recurse on all the node's children no matter what. Could you please switch to that? It's a bit less code and better practice to minimize recursive calls (since they can get tricky in larger rules).
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.
Done f36d420
This reverts commit 2e0825f.
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.
This is looking great! A few simplifications to the internals and error message to go, I think.
Also, about the build failures: the build is running linting with this rule enabled and finding failures in TSLint's code base. So it looks like the rule is working! 😄 You'll need to fix those failures to get the build to pass.
src/rules/unnecessaryElseRule.ts
Outdated
} | ||
ts.forEachChild(node.thenStatement, cb); | ||
} else { | ||
return ts.forEachChild(node, cb); |
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.
Sorry @debsmita1 I think I wasn't very clear here. I'm suggesting you don't need to have ts.forEachChild
statements in the big if (utils.isIfStatement
block:
if (utils.isIfStatement(node)) {
// all your glorious rule logic here
// no ts.forEachChild in this area
}
ts.forEachChild(node, cb);
Note the lack of else
statement: a single ts.forEachChild
should recurse on all the node's children no matter what. Could you please switch to that? It's a bit less code and better practice to minimize recursive calls (since they can get tricky in larger rules).
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.
Whoohoo, this looks great! Thanks for sticking through review @debsmita1; very exciting to have this rule in! 🙌
(additional thanks for fixing all the complaints it found across existing source files...!)
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 find this rule pretty opinionated, sometimes impairing readability, and I don't want to enable this in the tslint codebase. Sorry I didn't get around to look at this before it got merged, but I think we should disabled this for tslint's own code in tslint.json
at the root of this repo, and I would not add it to tslint:recommended
or tslint:latest
.
it is unnecessary to add an \`else\` statement. | ||
The contents that would be in the \`else\` block can be placed after the end of the \`if\` block.`, | ||
ruleName: "unnecessary-else", | ||
type: "functionality", |
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 think this is a purely stylistic rule; is there any functional difference?
This reverts commit 88916a2.
PR checklist
Overview of change:
This Rule disallows
else
blocks followingif
blocks ending with areturn
,throw
,break
orcontinue
statement.Is there anything you'd like reviewers to focus on?
This is my very first open-source contribution, so all kinds of feedback is appreciated.
CHANGELOG.md entry:
[new-rule] unnecessary-else