1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
Consider an instance method that is not an override, is not overrideable itself,
and never accesses `this` (explicitly or implicitly) in its implementation. Such
a method can always be marked `static` without harm.
The main benefit of adding `static` is that a caller who wants to use the method
and doesn't already have an instance handy won't have to conjure one up
unnecessarily. Doing that is a pain, and in unit tests it also creates the false
impression that instances in multiple states need to be tested.
But adding `static` also benefits your implementation in some ways. It becomes a
little easier to read and to reason about, since you don't need to wonder how it
might be interacting with instance state. And auto-completion will stop
suggesting the names of instance fields and methods (which you probably don't
want to use).
This analogy might work for you: it's widely accepted that a method like this
shouldn't declare any parameters it doesn't actually use; such parameters should
normally be removed. This situation with `static` is fairly similar: in either
case there is one additional instance the caller needs to have in order to
access the method. So, adding `static` is conceptually similar to removing that
unused parameter.
## Suppression
Methods which are used by reflection can be annotated with `@Keep` to suppress
the warning.
The `@Keep` annotation can also be applied to annotations, to suppress the
warning for any member annotated with that annotation.
```java
import com.google.errorprone.annotations.Keep;
@Keep
@Retention(RetentionPolicy.RUNTIME)
@interface SomeAnnotation {}
...
public class Data {
@SomeAnnotation
int doSomething(int x) {
return x;
}
}
```
All false positives can be suppressed by annotating the variable with
`@SuppressWarnings("MethodCanBeStatic")`.
|
