Viewing the examples generally, the second one better communicates hierarchy at the cost of an extra line. The arguments are all grouped together visually and without distraction, while in the first example the first argument gets muddled with the function name. Why? To save a line break?

The canonical notation is like this:

  func(arg1, arg2, arg3)

the first example splits it across multiple lines in a way which maximally preserves the other aspects of the notation.

The argument is already being muddled with the function in the same way.

These conventions are seen in the wild:

  func (arg1, arg2, arg3)

and

  func( arg1, arg2, arg3 )

The real fix for that muddling is to drop the commas, and move the parenthesis to include the function:

  (func arg1 arg2 arg3)

Now func and arg1 are no more or less muddled than are arg1 and arg2. :)

> the first example splits it across multiple lines in a way which maximally preserves the other aspects of the notation.

Once you’re splitting it across lines I don’t think that is a desirable attribute. Better to use a format that suits multiple lines than attempt to match as closely as possible to a format intended for one line. Like those “flying cars” that try to look like the “canonical” car.

From my perspective this is a UI problem (though not a serious one).

Why? The purpose of code is to be readable to humans.

At the same time I get your point and also the argument about Git diffs (which also should be readable). So maybe the ideal situation would be a separation of code and its formatting, so that we have more options than tabs and also no need for crutches like tabs. Like a better, more flexible code formatter that lets you display and edit code in the editor using one style but then saves the file in a standard format that's consistent across the whole project.

That’s what many auto formatter do anyways, even ones setup for fixed width fonts.

Honest question: which one is unintuitive?