You don't need a monospaced font to line up multiline expressions or function arguments. All you have to do is use indentation instead of column alignment. In other words, follow the same rules for expressions that you most likely already use for statements.

For example, instead of this:

  someObject.someMethod(oneArgument,
                        anotherArgument,
                        oneMoreArgumentForTheRoad);

Format it exactly as you would if the parentheses were curly braces:

  someObject.someMethod(
      oneArgument,
      anotherArgument,
      oneMoreArgumentForTheRoad
  );

Or instead of this:

  string someVariable = oneThing +
                        anotherThing +
                        yetAnotherThing;

Do this:

  string someVariable =
      oneThing +
      anotherThing +
      yetAnotherThing;

The code is just as readable this way, and you gain many benefits:

* Your code looks exactly the same in a proportional or monospaced font, so people viewing the code are free to choose either.

* You no longer need to fiddle with adding or removing spaces when you change the length of one of your variables or function names.

* The diffs in your revision history no longer show spurious changes that result from that column fiddling.

* Your code lines become much shorter.

* Instead of having one formatting rule for curly braces and a completely different rule for parentheses, you use the same formatting rule for everything.

* It doesn't matter if the code is indented with spaces or tabs. With no column alignment, rules like "tabs for indentation, spaces for alignment" are no longer needed.

* If you need to change the code to a new indentation style (e.g. change 2 or 4 spaces to tabs, or vice versa), you can do that reliably with a simple regex search and replace, with no damage to the code formatting and no manual cleanup required.

I adopted this practice long before I switched to coding in proportional fonts - and once I started formatting code this way I realized that it didn't matter any more what kind of font I used. I was free to choose any font that pleased my eyes, with no impact on the readability of the code for those who prefer monospaced fonts.

A good place to see the problems that column alignment causes is the Servo source code, whose coding standard mandates column alignment. I posted a few examples here:

https://news.ycombinator.com/item?id=9469713

I've often wondered why column alignment is so popular given its drawbacks. I have a theory that I think explains some of it, at least in the case of function calls and parenthesized expressions.

It's because of the very common objection to putting spaces inside the parentheses. For example, PEP8 and many coding standards explicitly forbid this.

Here's what happens. Take my first example above, written as one line without spaces inside the parentheses:

  someObject.someMethod(oneArgument, anotherArgument, oneMoreArgumentForTheRoad);

That line is too long, so let's fix it. The natural starting place is to change every space to a newline:

  someObject.someMethod(oneArgument,
  anotherArgument,
  oneMoreArgumentForTheRoad);

That's a bit messed up, so what can we do? Indent the extra lines?

  someObject.someMethod(oneArgument,
      anotherArgument,
      oneMoreArgumentForTheRoad);

Ugh. Now the arguments don't line up at all. It's really ugly. The only cure is to align the columns:

  someObject.someMethod(oneArgument,
                        anotherArgument,
                        oneMoreArgumentForTheRoad);

But what if we adopted the practice of putting spaces inside the parentheses?

  someObject.someMethod( oneArgument, anotherArgument, oneMoreArgumentForTheRoad );

If we make the same substitution, changing each space to a newline, we get this:

  someObject.someMethod(
  oneArgument,
  anotherArgument,
  oneMoreArgumentForTheRoad
  );

And now it makes perfect sense to indent the arguments:

  someObject.someMethod(
      oneArgument,
      anotherArgument,
      oneMoreArgumentForTheRoad
  );

This is the same thing we intuitively do with curly braces. After all, hardly anybody codes like this:

  while(true) {oneStatement;
               anotherStatement;
               oneMoreStatement;}

I think one reason is that we pretty much tend to put spaces inside the curly braces, even in a one-liner. It's not too common to write this:

  while(true) {oneStatement; anotherStatement; oneMoreStatement;}

Instead, this seems more typical (if you use a one-liner at all, which I'm not arguing for or against):

  while(true) { oneStatement; anotherStatement; oneMoreStatement; }

No one seems to mind spaces inside the braces, but I've had developers totally freak out over the idea of putting spaces inside the parentheses. It Simply Is Not Done.

I don't understand why there's such an objection to that, especially when it seems to lead directly to the difficulties of column alignment.

I tend to think that it's because spaces never go inside the parentheses in English text. But this is code, not English, and we are free to choose conventions that benefit us, even if they differ from how we'd write prose.

Edit: I added a number of thoughts after first posting this. If you upvoted this an earlier version of this comment and now think I'm insane for advocating spaces inside the parentheses, let me know and I'll post another comment that you can downvote. ;-)