Soften wording for rule to avoid using default in switch statements

[calda]

Summary

We have a rule that suggests to avoid using the default case when switching over an enum.

This rule is worded pretty strongly ("never use the default case"), but lacks autocorrect or linting, so has no enforcement. I also think there are valid reasons to use the default case.

I think we should just soften the wording of this rule (not use strict wording like "never"), since it is still good advice overall.

Some alternatives we could consider:

1. Add a lint rule to enforce this rule
   • This is too heavy-handed, because there are valid use cases for using default. The prose rule includes a set of exceptions where it can make sense to use default.
   • This is infeasible, because a linter wouldn't know if we are switching over an enum or not. We may be switching over something that can't be switched over exhaustively, which would require a default case. (edit: Michael has suggested some heuristics we could use to reduce the number of false positives here without needing full type information).
2. Remove this rule completely
   • We don't have many rules that are mere suggestions, without any linter enforcement or autocorrection. We haven't added any new rules like this in many years.
   • I think we should continue to permit this sorts of rule, which makes recommendations that can result in higher-quality code but aren't strictly enforced. This is probably the biggest "expansion opportunity" for the content in our style guide.

Reasoning

Please react with 👍/👎 if you agree or disagree with this proposal.

[bachand]

My opinion is that we should keep this rule worded as-is.

In a large codebase, it can be very hard (I would argue infeasible) to validate all switch statements over an enumeration when adding a new case. This style guide rule makes that intractable validation problem trivial to validate, since the compiler does the work for us. IMHO the huge time savings and increase in confidence that this rule brings justifies the lack of enforcement and autocorrection. Our style guide indicates that exceptions should be heavily justified.

I think this is one of the cases where the benefits of an unenforceable rule outweigh the exceptionality of it.

[calda]

Worked with @bachand to workshop and simplify the changes

[bachand]

My opinion is that we should keep this rule worded as-is.

In a large codebase, it can be very hard (I would argue infeasible) to validate all switch statements over an enumeration when adding a new case. This style guide rule makes that intractable validation problem trivial to validate, since the compiler does the work for us. IMHO the huge time savings and increase in confidence that this rule brings justifies the lack of enforcement and autocorrection. Our style guide indicates that exceptions should be heavily justified.

I think this is one of the cases where the benefits of an unenforceable rule outweigh the exceptionality of it.

Worked with @bachand to workshop and simplify the changes

Thanks for taking the time to work through this one together @calda . The large number of places in our codebase that are in conflict with this rule as well as the reasonable exceptions that we discussed (partially documented in the new examples) convinced that we should in fact soften the wording.

[bachand]

🎉