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

Rule request: fallthrough should be avoided #1834

Closed
2 tasks done
marcelofabri opened this issue Sep 11, 2017 · 0 comments
Closed
2 tasks done

Rule request: fallthrough should be avoided #1834

marcelofabri opened this issue Sep 11, 2017 · 0 comments
Labels
rule-request Requests for a new rules.

Comments

@marcelofabri
Copy link
Collaborator

marcelofabri commented Sep 11, 2017

New Issue Checklist

Rule Request

Avoid fallthrough inside switch statements.

  1. Why should this rule be added? Share links to existing discussion about what
    the community thinks about this.

Using fallthrough makes code harder to read and, in most cases, can be replaced by combining cases. LinkedIn's Swift Style Guide also thinks that (item 3.4.5).

  1. Provide several examples of what would and wouldn't trigger violations.
// should trigger
switch foo {
case .bar:
    fallthrough
case .bar2:
    fallthrough
case .bar3
    something()
}


// shouldn't trigger
switch foo {
case .bar, .bar2, .bar3:
    something()
}
  1. Should the rule be configurable, if so what parameters should be configurable?

Only severity.

  1. Should the rule be opt-in or enabled by default? Why?
    See README.md for guidelines on when to mark a rule as opt-in.

Opt-in. In the end, this is still a matter of style and there are situations where you can't just combine cases.

@marcelofabri marcelofabri added the rule-request Requests for a new rules. label Sep 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rule-request Requests for a new rules.
Projects
None yet
Development

No branches or pull requests

1 participant