Formatting multiple arguments passed to a function

问题:

Often the number of arguments passed to a function can be large. Consider the following case:

calculate(dataManager.getLastUpdate().getNumberOfChildren(),
          dataManager.getLastUpdate().getNumberOfParents(),
          dataManager.getLastUpdate().getNumberOfGrandChildren(),
          long milliseconds,
          int somethingelse)

Is there a guideline in Java that offers a way to align the arguments? Fitting all arguments in a line would not look pretty.

回答1:

According to the Sun's Java coding conventions, paragraph 4.1 "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 the 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.

The document also includes some examples for method calls:

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

var = function1(longExpression1,
                function2(longExpression2,
                          longExpression3));

回答2:

When I have to call a method like this I like to put the arguments on their own line, like so:

final int result = calculate (
    dataManager.getLastUpdate().getNumberOfChildren(),
    dataManager.getLastUpdate().getNumberOfParents(),
    dataManager.getLastUpdate().getNumberOfGrandChildren(),
    milliseconds,
    somethingelse
);

Obviously this is a personal preference, but if you're working with others on code, try to conform to the conventions already set forth.

回答3:

I'll put my little sand grain here, long time ago some developer named Esteban suggested me this kind of formatting, which I 1st thought it was ugly after a while no other way of doing it is enough pleasent for me:

final int result = calculate (
     dataManager.getLastUpdate().getNumberOfChildren()
     , dataManager.getLastUpdate().getNumberOfParents()
     , dataManager.getLastUpdate().getNumberOfGrandChildren()
     , long milliseconds
     , int somethingelse
     );

I find this really clear, very easy to add/delete new arguments, the # of arguments clear, only one argument per line, method call end really clear, etc...

Similar pattern for defining the method too

public int calculate(
    final int numberOfChildren
    , final int numberOfParents
    , final int numberOfGrandChildren
    , final long milliseconds
    , final int somethingelse
    ) throws CalucalteExceptio {

     // MyCode

    }

And finally same pattern for nested calls, StringBuilder typicall sequence

   StringBuilder sb = new StringBuilder()
       .append('Children #').append(numberOfChildren).append(NL)
       .append('Parents #').append(numberOfParents).append(NL)
       .append('GrandChildren #').append(numberOfGrandChildren).append(NL)
       ;

The only problem I found is that IDE formatters never allow this 'comma at the beginning' approach which is really interesting, and a lot more readable than any other I've tried.

Hope it adds something interesting

回答4:

I might assign the return values of the getNumberOf*() methods to variables:

SomeObject lastUpdate = dataManager.getLastUpdate();
int children = lastUpdate.getNumberOfChildren();
int parents = lastUpdate.getNumberOfParents();
int grandChildren = lastUpdate.getNumberOfGrandChildren();
calculate(children, parents, grandChildren, milliseconds, somethingelse);

回答5:

Referring to your example, Eclipse and other IDEs format it the way you have above (1 argument per line, all left aligned) and usually that looks pretty good.

回答6:

I wholeheartedly agree with your example of having one argument per line, all lined up under each other.

It makes it very easy to scan down the list to see what is there or what is missing.

It also makes it easier to document null values as being "// user id" or something similar.

I find it's particularly easy to visually parse, rather than having several long lines of densely packed values that may often look alike.