-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Mismatch between the synopsis and enforcement of rule Enum.2 #2123
Comments
I think that it is not necessarily dead code, it depends on whether there's |
Agreed, although this is considered bad practice in most cases. Note that my request is not about this extra enforcement but making sure the rule synopsis and enforcements are aligned. Can you say something about that? |
I already noticed that your "request" contained different aspects. I think you might be onto something and it would be nice to see a better suggestion or change request. Good luck! |
Thanks for your answer. Concerning the "Agreed, although this is considered bad practice in most cases." I thought the evidence was clear. If you don't have a "break" (or any other control flow changer such as "throw", "return", ...) at the end of a non-empty case in a switch statement, you will get a fall through, which is warned about by almost all compilers e.g. -Wimplicit-fallthrough by gcc and clang. But once again, this request is to have the enforcement and the synopsis aligned for rule Enum.2. Can this be picked up? |
The synopsis of rule Enum.2 is "Use enumerations to represent sets of related named constants" and the enforcement of this rule is about flagging switch statements for enumerations that don't cover all enumerators. The enforcements certainly make sense but if you violate these it doesn't mean that you haven't "Used enumerations that don't represent sets of related named constants". These are completely unrelated.
Since I think the enforcements are great, they should be kept. It would better to change the synopsis to something like "Make sure all cases are covered when using a switch statement".
Note that a third enforcement could be added in this context:
The reason for this is that the default is actually dead code in such a case. But more importantly, the other enforcements will not trigger if there is a default because the default will cover the new enumerator.
The text was updated successfully, but these errors were encountered: