Enforce existence of parameter-name comments in more cases
- Dominant language
- Java
- Stars
- 7.2k
- Forks
- 820
- Avg merge
- 5h 9m
- Merged PRs (30d)
- 50
Description
With parameter-name comments, I refer to the `foo(/* bar = */ ...)` comments for which [ParameterName](https://errorprone.info/bugpattern/ParameterName) checks correctness if they exist. The *existence* of such comments is currently only checked by [BooleanParameter](https://errorprone.info/bugpattern/BooleanParameter) for boolean parameters with severity "suggestion".
I would like to propose adding more checks that enforce existence of such comments, either
- for series of identically typed primitive parameters (`foo(Object, int, int)` etc.) with minimum length 2 or 3 or
- by having an annotation like `@MustUseParameterNames` that could be added to the function definition.
This could likely help avoid more bugs. Of course, a builder is an alternative, but especially for cases with a low number of parameters and a low number of callers, most developers would probably not bother writing a builder, but such cases can still produce bugs. Enforced parameter names would thus be valuable.
Concrete example that triggers this feature request: In one of our projects we have a class C that takes 3 int arguments in its constructor, and as it is a low-level class it would not make sense to replace these with non-primitive types. There is also only a single place where instances of C are created in production code, so nobody bothered with a builder. However, later on a new developer mixed up the order of parameters for this constructor when writing tests for components that get C instances as inputs, and thus the new components ended up working incorrectly without the tests failing. Error Prone would have correctly identified the problem via the ParameterName check if such comments were used, but they were not. If Error Prone would have enforced parameter names or we could have marked the constructor as requiring them, chances are good that this would have been caugth.
Contributor guide
Assessment
This issue has not been assessed yet.