Placing arguments on their own lines [closed]

Question

This question applies to both parameters and arguments, since I've seen this style used in both.

I usually write parameters like this

someFunction(arg0, arg1, arg2)

but I've recently noticed that many people write theirs like this

someFunction(
arg0,
arg1,
arg2
) // the bracket doesn't have to be on its own line

I have a multi-faceted question here:

1) Is it standard practice, good practice, or negligible to put each argument on their own lines?
2) Are their exceptions to this style, like when there is only one argument?
3) What are the pros and cons of such a design?

Answer 1

As with any code formatting questions, it is largely a matter of opinion and of context.

If you are passing a small number of parameters and the parameters are local variables rather than the result of some other method, having everything on one line tends to make code easier to read because it is appropriately compact. If, on the other hand, you are passing a relatively large number of parameters and the parameters are the result of calling other methods, separate lines are often better from a readability standpoint because you're not trying to follow dozens of operations in a single line of code.

In other words, if I have something like

log( base => 2, exp => 8 )

it's much easier to see on a single line. On the other hand, if I have something like this where I'm instantiating one object and passing a value to a constructor, calling a method on another object, computing a value from one local variable, passing in another local variable, and using a constant, it would be very difficult to follow on a single line of code. You'd need multiple lines just to be able to see everything at a glance.

someBusinessFunction( new SomeObject( "file_name.txt" ),
                      anotherObject.GetListOfAddresses(),
                      aLocalVariable,
                      (case when someLocalVariable then 'Y' else 'N' end),
                      ASYNC_MODE );

Of course, ideally, you'd probably want method signatures that are simpler rather than signatures that are overly complex all else being equal. But sometimes methods make more sense when they accept a few parameters. You could, of course, also create multiple intermediate variables on multiple lines of code and then call the function on a single line of code. That may or may not simplify the logic overall, though. You'd still have at least as many lines of code but now you'd have a few additional local variables to keep track of.

Answer 2

There are actually three different ways for routine-header layout (Code Complete 2):no conscious layout, endline layout and standard indentation. The preferred method being the standard indentation

No conscious layout

The parameters are laid out one after another, with no arrangement whatsoever

bool ReadData(string employeeName, int employeeAge, int yearsOnJobMarket, bool isOperationSuccesful)

These routines are seen as purely utilitarian in that both computers and humans can read them, but they cause trouble for humans.

Endline layout

bool ReadData(string employeeName, 
              int    employeeAge, 
              int    yearsOnJobMarket, 
              bool   isOperationSuccesful)  

This approach is neat and aesthetically appealing. The main problem is that it takes a lot of work to maintain, and that usually means it isn't maintained. For example, if the routine name changes to ReadNewData, your layout will look like this:

bool ReadNewData(string employeeName, 
              int    employeeAge, 
              int    yearsOnJobMarket, 
              bool   isOperationSuccesful) 

so now you either have to manually change the indentation of all the other parameters, or just forget about it and leave it as it is.

Standard indentation

bool ReadData(
    string employeeName, 
    int employeeAge, 
    int yearsOnJobMarket, 
    bool isOperationSuccesful
)

Now, in this case, you don't have to change anything if your routine name changes, or you add/delete new parameters. It looks good for the eyes, it's readable and maintainable.

Again, these are not my ideas, but are taken from Code Complete 2 by Steve McConnell