File: UngroupedOverloads.md

package info (click to toggle)
error-prone-java 2.18.0-1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm, forky, sid, trixie
  • size: 23,204 kB
  • sloc: java: 222,992; xml: 1,319; sh: 25; makefile: 7
file content (20 lines) | stat: -rw-r--r-- 931 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
The [Google Java Style Guide ยง3.4.2.1][style] requires overloads to be grouped
together:

> When a class has multiple constructors, or multiple methods with the same
> name, these appear sequentially, with no other code in between (not even
> private members).

Overloaded methods/constructors represent the same functionality, but with
different modes of interaction with the caller. They belong together. More
concretely, one danger of splitting overloads is that someone looking for one
but finding the other may easily assume the other does not exist.

If the ungrouped overloads do not represent the same functionality, consider
renaming the methods.

NOTE: this rule implies that a private helper used by a single method, which you
might normally place just below that method, should be placed below *all*
overloads of that method.

[style]: https://google.github.io/styleguide/javaguide.html#s3.4.2.1-overloads-never-split