[pmontra]

I've been using proportional fonts in programming for about ten years. I stopped doing things like

  abc = 1
  d   = 2

which add very little readability value IMHO.

Things like

  func(arg1,
       arg2,
       arg3)

usually don't align well because func( has a different width than the five spaces in the lines below. However

1) my text editor (emacs) aligns those lines for me (probably any programmer's editor does) so at least I don't have to do precision work

2) I ended up writing code like

  func(
    arg1,
    arg2,
    arg3
  )

especially with named arguments (arg=value). That aligns even with proportional fonts and all arguments immediately stand out.

If the arguments are few (two or three) and there are no named arguments I don't break them on multiple lines.

The result is that no coworker ever complained about my code.

Languages with a formatter (Elixir) solve the problem once and for all and align well with both kinds of fonts.

[anilakar]

Formatting your code in an unintuitive way because of the font is a code smell to me.

[nkrisc]

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?

[kazinator]

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. :)

[nkrisc]

> 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).

[alpaca128]

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.

[seanmcdirmid]

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

[pmontra]

Honest question: which one is unintuitive?

[amadvance]

I do something similar also with if() and others:

  if (condition...
      && condition...
      && condition...
  ) {

[tuyiown]

Same here but pushed it to force same column condition statement:

    if ((
      condition1
    ) && (
      condition2
    ) && (
      ...
    )) {

[Izkata]

But that loses the table-like structure and makes it harder to read.