-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Turn on no-fallthrough rule #11093
Turn on no-fallthrough rule #11093
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -54,16 +54,18 @@ export default function isReferenced( | |
if (parent.params.includes(node)) { | ||
return false; | ||
} | ||
// Fall-through to next case clause to check whether the node is the method's name. | ||
// fall through | ||
|
||
// yes: { [NODE]: "" } | ||
// no: { NODE: "" } | ||
// depends: { NODE } | ||
// depends: { key: NODE } | ||
// fall through | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @kaicataldo The comment on line 57 is not enough. Could eslint/eslint#10608 be reopened? 🙏 😅 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if we should allow it to be either the first or last, but not the middle? I know it's unlikely, but I think it would be good to avoid something like this triggering it: /* eslint no-fallthrough: ["error", { "commentPattern": "fall-through[\\s\\w]*not allowed" }] */
switch(foo) {
case 1:
doSomething();
// We don't want to fall through here
// because fall-through is not allowed,
// oh look, a run on sentence.
default:
doSomething();
} There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Doesn't this code already have that problem? /* eslint no-fallthrough: ["error", { "commentPattern": "fall-through[\\s\\w]*not allowed" }] */
switch(foo) {
case 1:
doSomething();
// We don't want to fall through here because fall-through is not allowed.
default:
doSomething();
} There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, it would. Might just be me, but the grouped line comments seem more error prone. It probably is the same thing in practice, though. |
||
case "ObjectProperty": | ||
// no: class { NODE = value; } | ||
// yes: class { [NODE] = value; } | ||
// yes: class { key = NODE; } | ||
// fall through | ||
case "ClassProperty": | ||
case "ClassPrivateProperty": | ||
if (parent.key === node) { | ||
|
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 hate that prettier doesn't include this comment, since conceptually it's a control flow statement similar to
break
/continue
.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.
Classic ambiguous comment indentation 😆