In certain contexts literal arguments - such as 0, "", true and false,
or null - can make it difficult for readers to know what a method will do.
Defining methods that take boolean parameters or otherwise expect users to pass
in ambiguous literals is generally discouraged. However, when you must call such
a method you’re encouraged to use the parameter name as an inline comment at the
call site, so that readers don’t need to look at the method declaration to
understand the parameter’s purpose.
Error Prone recognizes such comments that use the following formatting, and emits an error if the comment doesn’t match the name of the corresponding formal parameter:
booleanMethod(/* enableFoo= */ true);
Varargs methods are also supported using ... syntax: void varargsMethod(/*
states...= */ true, true, false);
The check also recognizes comments with whitespace variations, e.g. /*foo =*/,
but the form /* foo= */ is preferred.
If the comment deliberately does not match the formal parameter name, using a
regular block comment without the = is recommended: /* enableFoo */.
Suppress false positives by adding the suppression annotation @SuppressWarnings("ParameterName") to the enclosing element.