What is an acceptable way to format a long method call in Java?

Question

Is it good style to write:

objectName.methodWithManyParameters(someLongParameter1, someLongParameter2, someLongParameter3, someLongParameter4, someLongParameter5);

(which is obviously far to long for one line) as

objectName.methodWithManyParameters
(
    someLongParameter1, 
    someLongParameter2, 
    someLongParameter3, 
    someLongParameter4, 
    someLongParameter5
);

Another way would be:

objectName.methodWithManyParameters(someLongParameter1, someLongParameter2, 
                                    someLongParameter3, someLongParameter4,
                                    someLongParameter5);

Answer 1

If you're working with others, or in a pre-existing code base, use whatever standards they've already been using. 80 vs 100 column, option #1/2/3, etc.

If you're working on your own, Jordi's answer nails it. Use the Oracle conventions, and likely go with 100 character line lengths; we have modern screens that fit a lot, lot more text than monitors did in 1996.

Answer 2

As far as I know there is no standard way of line wrapping. It is either a matter of personal preference or of company internal coding style standards. However, I recommend to read Google Java Style. Below is the quote from there that might be relevant.

My personal preference is as follows (hope it helps):

objectName.methodWithManyParameters( someLongParameter1, 
                                    someLongParameter2, 
                                    someLongParameter3, 
                                    someLongParameter4, 
                                    someLongParameter5 );

4.4 Column limit: 80 or 100

Projects are free to choose a column limit of either 80 or 100 characters. Except as noted below, any line that would exceed this limit must be line-wrapped, as explained in Section 4.5, Line-wrapping.

Exceptions:

Lines where obeying the column limit is not possible (for example, a long URL in Javadoc, or a long JSNI method reference). package and import statements (see Sections 3.2 Package statement and 3.3 Import statements). Command lines in a comment that may be cut-and-pasted into a shell. 4.5 Line-wrapping

Terminology Note: When code that might otherwise legally occupy a single line is divided into multiple lines, typically to avoid overflowing the column limit, this activity is called line-wrapping.

There is no comprehensive, deterministic formula showing exactly how to line-wrap in every situation. Very often there are several valid ways to line-wrap the same piece of code.

Tip: Extracting a method or local variable may solve the problem without the need to line-wrap.

4.5.1 Where to break

The prime directive of line-wrapping is: prefer to break at a higher syntactic level. Also:

When a line is broken at a non-assignment operator the break comes before the symbol. (Note that this is not the same practice used in Google style for other languages, such as C++ and JavaScript.) This also applies to the following "operator-like" symbols: the dot separator (.), the ampersand in type bounds (), and the pipe in catch blocks (catch (FooException | BarException e)). When a line is broken at an assignment operator the break typically comes after the symbol, but either way is acceptable. This also applies to the "assignment-operator-like" colon in an enhanced for ("foreach") statement. A method or constructor name stays attached to the open parenthesis (() that follows it. A comma (,) stays attached to the token that precedes it.

Answer 3

According to Oracle conventions:

4.2 Wrapping Lines

When an expression will not fit on a single line, break it according to these general principles:

• Break after a comma.
• Break before an operator.
• Prefer higher-level breaks to lower-level breaks.
• Align the new line with the beginning of the expression at the same level on th previous line.

If the above rules lead to confusing code or to code that's squished up against the right margin, just indent 8 spaces instead.

Here are some examples of breaking method calls:

someMethod(longExpression1, longExpression2, longExpression3, 
        longExpression4, longExpression5);

Resuming

Second option is the standard convention, first is more readable, but can harm in really long methods or if many calls because of the lenght of the classes...