Fuck alignment.

  [tab]void someNiceMethod(
  [tab][tab]int myParamA,
  [tab][tab]int myParamB,
  [tab][tab]...
  [tab]);

Exactly. I never understood the benefit of alignment. I actually find it harder to read - by making the starting point of the line less predictable it's harder to skim through and if, say, you rename the function you've now got a much longer diff than necessary.

After talking to several people, I've realised this is very subjective though (what isn't!). I certainly prefer indenting only, without worrying about alignment.

> Exactly. I never understood the benefit of alignment.

Alignment is what makes ASCII art possible. Without alignment, we might as well be using modern proportional fonts rather than old-fashioned type writer fixed-width fonts (ducks).

I know some of my coworkers still use mono-spaced fonts and I just don't understand it. Proportional fonts are so much more legible and nicer to look at.

I can't stand code in a proportional font. I like aligning code and having the alignment be maintained, regardless of the specific font in use. Things tend to also be more smooshed-together and hard to read individual characters when using proportional fonts, since every character's width varies, instead of matching the widest character.

Aside from that, in the stylistic sense, it's like reading a newspaper article in cursive or an academic paper in comic sans.

Those are the things that struck me when I've pasted code into an editor with proportional fonts, anyhow.

There are other proportional fonts than cursive ones or Comic Sans MS. You should just use better fonts.

Of course there are; I wasn't suggesting those as appropriate fonts. I was using them as extreme examples of stylistic mismatch.

Proportional fonts have less mismatch when used for code, but they still tend to look "wrong" to me. A font like "Input" is attractive and offers proportional and monospaced versions. You're still left with the larger problem: fighting the font to line up data across multiple lines.

Maybe you don't care about that, but in both my hobby and professional projects, I've found that alignment makes the code easier to read and easier to work with. I would need a very compelling reason to abandon that, and I haven't seen one offered.

Going back to your original comment, you said:

> Proportional fonts are so much more legible and nicer to look at.

You also provided a convenient reply, which I think applies here:

> You should just use better fonts.

Hack, Input Mono, and a zoo of others are very attractive monospaced fonts. You aren't stuck with whichever ugly ones you're thinking of.

Character spacing, kerning, ligatures, and many other aspects of modern typography are all that you give up with type writer fonts. Yes, if you use a shit font like Times New Roman, it will look bad, but if you use a nice San Serif font, it doesn't look as you described (like cursive, comic sans, or another pseudo hand writing font).

Yes, you give up the ability to do ascii art in your code. I find that this doesn't really matter to me or much of the code I use professionally (I can open up some random javascript code off of GitHub and they don't do non indent alignments). I guess if I was programming in C, this might be much more of a problem.

I totally agree. You can fight with alignment all day and it's not worth it in my opinion. Just have it indented on a new line and call it a day.

It's not so bad if you use a formatter (still prefer indenting though), but if you align everything by hand it's just more annoying than it is useful (in my opinion).

I also follow this approach. I also use these other rules:

    var something =
    [tab]someReallyLongCallThatWouldExceedMargin()

    someObject
    [tab].call()
    [tab].otherCall(param)
    [tab].yetAnother(
    [tab][tab]withLong,
    [tab][tab]parameters);

I use four literal spaces, but I think this approach would work well with literal tabs. The only problem is most IDEs do not have an expressive enough configuration to do this, nor do I think I could make it easily happen out of the box with tools like indent or gofmt.

I could be equally condescending and say "Why Grown-Ups Don't Use Column Alignment."

But using alignment doesn't mean you are childish. It's just a bad habit that leads to many problems.

A couple of examples from the Servo source code, whose coding standard at one time required column alignment:

    let construction_item = ConstructionItem::TableColumnFragment(Fragment::new(node,
                                                                                specific));
  
    self.set_flow_construction_result(&kid,
                                      ConstructionResult::Flow(kid_flow,
                                                               Descendants::new()))

There's no good reason for these lines to be so long. If they were formatted with indentation as shown in hawski's example, they would be much shorter.

Another example from an earlier version of the code:

  ConstructionResult::ConstructionItem(ConstructionItem::Whitespace(whitespace_node,
                                                                whitespace_style,
                                                                whitespace_damage)) => {
      ...
  }

Wait, is this aligned or not? What happened? Most likely it was aligned at one time, and then some names were changed and it became misaligned.

If you use indentation instead of alignment, these problems never happen. And in fact, the Servo coding standard finally allows the use of indentation, and this particular call has been changed to use it.

Now back to the question of tabs and spaces. If you use tabs and only use indentation with no alignment, then it doesn't matter what anyone uses for their tab width. The code will always look perfect whether someone likes their tabs rendered as 2, 4, 8, or any number of spaces.

The code will also look fine for someone like me who prefers proportional fonts. In fact, I think every developer should try using a proportional font for a while. It's a good way to get over the bad habit of column alignment.

I'd argue that the real issue here is slavish adherence to the style guide without stopping to consider what's readable. Alignment, in my opinion, is a readability win in general. (We may have to agree to disagree here.) But when column alignment results in unreadable code like the examples you gave, you shouldn't use it. It's that simple. That doesn't mean that column alignment as a general principle is bad; you should optimize for the common case, and be willing to handle exceptional cases differently.

A similar issue is formatting for 80 columns. In general, this is a good idea, because long lines can be hard to read and hard to edit. That doesn't mean that you should contort the formatting of your code in bizarre ways to avoid an 85 character line.

ConstructionItem::TableColumnFragment is 37 characters[1]. A style that permits huge identifiers like that should allow more than 2.2 identifiers per line and should not allow alignment that requires the eye to jump over that much whitespace and land on the correct line.

[1] not columns. Bitmapped displays don't have columns, and it's objectively measurable that humans read fixed-pitch fonts more slowly.

Linux uses with tabs and fixes the amount of spaces a tab is equivalent to is 8 spaces (for visual alignment)

Problem solved and it works for them

At that point they're getting negative value out of tabs - people can't set different tab widths and also can't use editors that don't use a width of 8 (or need to reconfigure editors that have a different default). They'd be better off just using spaces.

No, they aren't (but you're free to disagree) and any editor worth their salt can alter how many spaces a tab is displayed with.

I was going to say you're obviously incorrect because in what editor can't you change your tab width? But I realized you are probably talking about the kernel.org project. Is that what you mean? There is an agreement within the Linux kernel project?

Yep, right at the start of the kernel style guide: https://www.kernel.org/doc/Documentation/process/coding-styl...

Wow, didn't remember how inconsistent the Linux coding style is. Or all C basically.

Yes, Linux is the Linux Kernel in this context (in kernel.org)

>IDEs aren't created equal

Shoot, just myself using a single IDE I always end up with spaces and tabs and missing indents and oddities. When I have something that's nested and I copy/paste it into another file, some of the spaces/tabs get preserved, some don't, and I end up having to either reformat it or ignore it, and then I forget which div closes which and it's just a headache.

The "show whitespace" features of most IDEs will make the space vs. tab issue apparent. The only down side is then you start secretly hating every other dev who doesn't use this feature.

But the problem only happens when you use tabs _and_ spaces. Don't blame the tabs!

"I think we can all agree that compromise is not an option"

~Humanity

`grep -A 1 "void someNiceMethod" src.java`

(╯°□°）╯︵ ┻━┻