[jcranmer]

It doesn't really solve the problem. How do you format this code with tabs:

  <TAB><TAB>function name(arg1, arg2,
  <TABs or spaces?????>   arg3 <-- align with arg1)

The other issue is with maximum line length. If you have a maximum line length of 80, do tabs count as 2 spaces, 4 spaces, or 8 spaces towards meeting that line length?

Using spaces ensures that it at least looks consistent, independent of your tabstop settings.

[dkersten]

Indent with tabs, align with spaces. Alignment never follows any "N number of spaces" style guide, since by definition its to align with something else.

So in this case:

  <TAB><TAB>function name(arg1, arg2,
  <TAB><TAB>              arg3

since we were talking about indention, not alignment, I don't see how anything changes. If I want my indent to be 3 spaces and you want 8, we can set our tab width and arg3 will still be aligned correctly for both of us.

Or you live with misaligned arguments (its a bit of a smell imho to have so many arguments that you need to split them over many lines, although it for sure does happen) and just use tabs for both.

My main point is that with tab, each individual has some control over their preferences, even if not perfect for alignment, while with spaces everyone has to live with the standard and nobody has control over their preference. That is, tabs is "mostly people get what they want", spaces is "nobody gets what they want unless they happen to want the style guide imposed on them". The former seems a lot better to me!

[stickfigure]

You learn to live without precisely aligned arguments!

Really this is a peculiar kind of OCD. You don't need to have arg3 precisely lined up with arg1. Or better yet, indent all the arguments in a nice column - if there's so many that they can't fit horizontally, render them vertically. Most IDEs default to two indentations for continuation.

[secondaryditto]

I've had some discussions with folks on projects who are very... focused on linting and formatting rules. They've reformatted my code in the past, and have insisted on blocking code that doesn't pass all their listing rules.

Them: "We have to use these tools to avoid disagreements about spacing and formatting choices".

Me: "But... I wasn't having any in the first place. It's only the 3 of you that were having these disagreements. And now you're spending ridiculous time planning reformat of entire codebase, instead of actually... moving the project forward.

Please don't bitch about me using $x = new Temp(); in a test file. I'm the only person on the project even making test files, and you're blocking my TEST file because you don't like variable name style..."

They got in to a quandary when trying to inline some JS in to a PHP view file. The PHP standard is 4 spaces, and the person doing some of the JS had defined 2 spaces for JS ("so we can all agree on it") and ... all hell broke loose trying to determine what the style/formatting should be for JS-inside-PHP files. 4 spaces? 2 spaces?

[ggregoire]

> It doesn't really solve the problem. How do you format this code with tabs:

  <TAB><TAB>function name(arg1, arg2,
  <TABs or spaces?????>   arg3 <-- align with arg1)

Just wondering… do you realign the parameters every time you rename a function?

[mikewhy]

    <TAB><TAB>function name(
    <TAB><TAB><TAB>arg1,
    <TAB><TAB><TAB>arg2,
    <TAB><TAB><TAB>arg3,
    <TAB><TAB>)

That means this never comes up, and you don't need to change adjacent lines because you've renamed a function.

[jlokier]

That wastes a lot of vertical space if you have a lot of function calls. If you're one of those who prefer that, it's ok. I much prefer:

    function name(arg1, arg2, arg3,
                  arg4, arg5, arg6);

[samvher]

Not the person you're responding to but I do, or actually spacemacs does. The sequence would be $ -> J -> i -> ENTER -> ESC and I guess it's muscle memory.

I agree that this kind of indentation might not make sense on a collaborative project because different people have different standards, but if I'm the only one working on a piece of code I really think precise alignment makes the code a lot more readable.

[benibela]

If the editor would support elastic tabstops you could do:

     <TAB><TAB>function name(<TAB>arg1, arg2,
     <TAB><TAB><TAB>arg3)

[jcranmer]

I don't actually personally do this kind of alignment, but it was the easiest example for me to come up with to illustrate the problem of needing to align text on different lines.

[1-more]

In elm you'd do one of two things: keep all the arguments on one line, or put each on its own line. At least, according to the formatter's opinion (which is honestly so nice to use when it just snaps everything into place every time you hit cmd-s). Of course, this convention is violated all the time when listing all the public exports of a package (with good reason IMHO; it lets your group similar things onto lines together) so it's not much of a convention: https://github.com/rundis/elm-bootstrap/commit/e412efe628854...

[marcus_holmes]

Go does this with tabs by either having each arg on its own line, or all on one line. Which totally makes sense.

[mrgriffin]

I wouldn't do it, but this works perfectly fine. The rule is "use tabs to indent blocks of code, use spaces to align within those blocks".

  <TAB><TAB>function name(arg1, arg2,
  <TAB><TAB>              arg3)