Split for other visibilities?

[oliviercailloux]

Section 3.4.2.1 forbids to split overloads.

The rule makes perfect sense for user visible methods, but what about inserting an invisible one in between visible ones?

Consider this situation.

• + m1(Integer param)
• + m1(Float param)
• + m1(Double param)
• - m1NumericHelper()
• + m1(String param)

Assume that m1NumericHelper() is a private helper method called by + m1(Integer param), + m1(Float param) and + m1(Double param) but not by + m1(String param). If a programmer likes to put such helper methods just after the ones that use them in general, it seems to make sense to also put this one just after these three methods.

It does not hurt usage as users will still see all (visible) methods grouped together.

Would the style guide admit an exception when private methods intervene in between public ones that share a name?

[eamonnmcmanus]

This is actually covered by an internal document, Auxiliary notes on the Google Java Style Guide, which Googlers can see at http://go/java-style-notes:

3.4.2.1 Overloads: Never split

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.

Note that 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.