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.

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!

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.

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?

> 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?

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

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

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.

If the editor would support elastic tabstops you could do:

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

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.

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

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

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)

My main objection to using tabs has always been that the Tab key is heavily overloaded: it navigates (one Tab press to move the cursor to the correct indentation point), selects (tab completion), and it puts a variable-width character into my monospace-defined text file.

I'd rather drop the insertion part and have my editor handle adding an appropriate number of spaces.

Let me add this: there's actually nothing stopping you from displaying a four-space indented file as a two-space indented file. Just parse, replace indentation-dictated groups of four spaces with two spaces, you're done.

I don't know of a plugin that does this for $your-favorite-editor but it's, y'know, software. There's nothing which prevents it.

yeah, but then your Version Control system thinks that you changed the file and it needs to commit that change.

Which is a ton more hassle than inserting tabs.

You could always make CapsLock insert a tab character so you keep the functions of the tab key separate from inserting a tab.

both?

What do you mean?

Tabs for indentation, spaces for alignment. It is called "smart tabs" and good text editors already implement it.

If you use spaces, you can check that files are okay by forbidding \t.

If you use tabs, you can check that files are okay by forbidding /^\t* /.

If you use tabs for indentation, spaces for alignment, ??????

My editor maintains it automatically, so it is never wrong. There is nothing to check.

I'm sure there is a command-line pre-commit formatter I could use. But I have never tried to set it up, since I can reformat existing code with a couple of keystrokes in my editor.

Forbid "\t* *\t"?

Ok, but if you get "\t[space][space][space][space]", how do you know this wasn't supposed to be "\t\t"? That is, how do you know trailing spaces are for alignment and not for indentation?

A code formatter knows, so your editor and other tools can also know.

Most editors have code structure parsing of some kind built-in for tabbing already. E.g. pressing the <tab> key indents the current line to match the structure of surrounding code (or cycles between valid indents for something like Haskell or Python). So they know the difference between initial indentation (that people want to be able to configure visually) and alignment.

is a joke: https://bigc.at/tabs-vs-spaces.orz