Ban the var keyword via error-prone VarUsage
#1788
Conversation
This will automatically migrate existing uses to the implementation type used by the `var` keyword.
Generate changelog in
|
| .addFix(fix.replace( | ||
| token.pos(), | ||
| token.endPos(), | ||
| SuggestedFixes.prettyType(state, fix, ASTHelpers.getType(typeTree))) |
There was a problem hiding this comment.
this will suggest using the concrete type instead of the interface which is typically prefered. It would be a ton of work to find the minimum type required of the variable though so its probably fine
There was a problem hiding this comment.
Maybe we just force the human to input the right type instead of a fix?
There was a problem hiding this comment.
I'd prefer to give them a starting point, the reviewer is responsible for ensuring the quality of the replacement. If the replacement quality is too low we can remove the suggestion.
If we don't automate any of it, they're more likely to turn off the check instead of fixing it themselves.
|
👍 |
|
Released 3.91.0 |
Before this PR
var?After this PR
This will automatically migrate existing uses to the
implementation type used by the
varkeyword.==COMMIT_MSG==
Ban the var keyword via error-prone
VarUsage==COMMIT_MSG==
Possible downsides?
Folks might use and enjoy the
varkeyword.I didn't update the readme to enumerate the new error-prone rule. It's already missing a few, and we should borrow the upstream html generator instead.