> Separately from the "lining things up" argument, though, there's an argument to be made for characters in any editing situation to be wider, even if they're not all the same width.

Have a look at Input [1]: a TrueType font built for coding, with somewhat-wide I and l and super-wide punctuation marks.

The issue is one of picking the right font, not of monospace vs. not - street signs, for example, have long used different fonts from printed pages, since they demand high accuracy and fast recognition of short chunks of text at long distances, as opposed to the pleasant long-reading experience demanded from most body fonts. Most systems just happen to have built-in variable-width fonts that are terrible for coding.

[1] [http://input.fontbureau.com]

I just started using Input, giving Anonymous Pro a little hiatus. It has been pleasant on the eyes.

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

This is pretty nice! I've been doing the same for Verilog module declarations (which can easily have 100 arguments):

    module fred(
        a,
        b,
        c
        );
    ...
    endmodule

I've not tried it for function calls, but it's not a bad idea...

How does it look for the case of an indented block after a while or a for? Let's see:

    while (
        a &&
        b && c
    ) {
        a = a + 1;
        b = b - 1;
    }

Hmm, maybe better than what I do now...

    while (a &&
           b && c) {
        a = a + 1;
        b = b - 1;
    }

Thanks! In fact, your first example of the while loop is almost exactly how I format it. The only very minor difference is that I don't put a space before the first parenthesis:

  while(
      a &&
      b && c
  ) {
      a = a + 1;
      b = b - 1;
  }

That's not a big difference; the only reason I leave out that one space goes back to my idea of having fewer formatting rules and special cases. I don't put a space before the open paren on a function call, so I don't put one there on a statement that has parens either. Not a big deal either way, I'm just lazy and like to have one rule instead of two. :-)

I experimented in the past with some other ways of formatting this kind of code, e.g.

    while (
        a &&
        b && c ) {
        a = a + 1;
        b = b - 1;
    }

Of course you can see the problem here - there's no visual separator between the while expression and the statements in the loop body.

That's why some coding standards require a double-indent:

    while (
            a &&
            b && c ) {
        a = a + 1;
        b = b - 1;
    }

That never appealed to me at all, but when I started moving the close paren to the next line and dedenting it there was no need for the double indent.

I always put whitespace after a keyword (like while) so that I can use regexps to find only function calls.

What about this?

  int c[] = {
       3,   6,   9,
      12,  15,  18,
  ...
     300, 303, 306
  };

or

  int v =
    ((r << 24) & 0xff000000) |
    ((g << 16) &   0xff0000) |
    ((b <<  8) &     0xff00) |
    ( a        &       0xff) ;

Those are nice - especially the second one, which is a great illustration of how you can use thoughtful alignment in a monospaced font to make the logic in a piece of code really stand out.

It's very different from the examples of column alignment I was critiquing in my earlier message, where there's an equally good or better way to format the code using indentation only.

All in all, I still prefer the visual appearance and compact nature of proportional fonts, especially my current favorite, Trebuchet MS - and they do just fine for almost all the code I write. But for all my criticism of column alignment, I have to admit I do miss it in cases like your second example where it brings clarity.

My dream editor would have a way to allow the use of both proportional fonts where they work well and monospaced fonts where they are better, all within the same file. Perhaps a special commenting convention that would let you switch back and forth.

One of the editors I use, Komodo, has a bit of this. When you create a custom visual theme, you can specify both a proportional font and a monospaced font, and either toggle the entire file back and forth with a hotkey or select one font or the other as part of syntax highlighting - similar to the way many editors let you select bold or italic for particular syntax elements. For example you can select a monospaced font for comments so you can do ASCII art there, while using a proportional font for other code.

Thanks for sharing those examples!

First I just want to thank you for the very pleasant reply. More often than not people online tend to get very religious and downright mean about things like convention like this, so thank you the dialog here has been refreshing.

You might be interested in literate programming:

https://en.wikipedia.org/wiki/Literate_programming#Tools

It's not exactly what you are after, but I think is more fundamentally what you are after - ways to make it easier to understand what code is doing. You can have the best of both worlds too here with something like noweb and two windows.

One other thing I ran into is a code base that had incredibly long lines (more than 132 often). So I started using ndiff to help me there. It's a python script that puts + and - under the lines where the differences are as well. I also wrote a little script to html it with different colors. It was pretty awful until I made it monospace too sadly.

Cheers!

    int v =
      ((r << 24) & 0xff000000) |
      ((g << 16) &   0xff0000) |
      ((b <<  8) &     0xff00) |
      ( a        &       0xff) ;

Is there a reason you're doing the shift before the mask? I find this much less intuitive than the equivalent

    int v =
      ((r & 0xff) << 24) |
      ((g & 0xff) << 16) |
      ((b & 0xff) <<  8) |
      ( a & 0xff) ;

Cause I was trying to exaggerate the effect of space to within reason somewhat?

Cause it was like 1AM here when I wrote it?

Take your pick ;)

Yeah I'd totally write the bottom way I think, or I hope, cheers.

I vaguely recall that Ruby promoted spaces inside parents, in part because Japanese (where Ruby started) programmers have some trouble with quickly visually separating parentheses from English letters when scanning code.

I believe what the comment you're replying to is implying multiple instances of indentation on the same line. Such as:

    if		( $test[0] )	func1()
    elseif	( $test[1] )	func2()
    elseif	( $test[2] )	func3()

That's a good point. Well, it was just an excuse for me to go off on a tangent! :-)

For the example you posted, I would classify that as column alignment rather than indentation. Just to clarify my terminology, what I call indentation is something that happens at the beginning of a line only. Any additional spacing after the first nonblank character is column alignment.

So the spaces before the if and elseif are indentation, and the extra spaces within the lines are column alignment (in my nomenclature).

The column alignment in your example is pretty appealing, but it does have some of the same problems as other forms of column alignment. When we get to ten or eleven tests, things have to get juggled around again. Do you do this:

    if		( $test[0] )	func1()
    elseif	( $test[1] )	func2()
    ...
    elseif	( $test[10] )	func3()

or this?

    if		( $test[0]  )	func1()
    elseif	( $test[1]  )	func2()
    ...
    elseif	( $test[10] )	func3()

or go all-out with something like this?

    if		( $test[ 0] )	func1()
    elseif	( $test[ 1] )	func2()
    ...
    elseif	( $test[10] )	func3()

I think basically I am just lazy and found all of this alignment so tedious that I looked for ways to avoid it. :-)

Elastic tabstops would solve this: http://nickgravgaard.com/elastic-tabstops/

I also use this convention, but one frustration is that no IDE wants to follow it in their auto line breaking functions.