> and it can always align perfectly.

I'm firmly in Team Tab, and I want to arrest any misconception that us Tabbers would do anything as nonsensical as using our precious variable-width tab-stop chars for anything like column-aligning identifiers: we don't.

My very hard and fast rule is that tabs are for only indenting at the block level, while spaces are used for alignment after the initial tab chars; tabs must never be used on a line if preceded by any non-tab char.

Whereas I can't stand always-using-only-spaces-for-indenting-and-alignment - especially because when you're drag-selecting text most editors won't snap your selection to the indent level, so you get RSI in your wrist from having to make micro-movements to make sure you don't select more - or less - spaces than the intended indent. ...or worse: when moving the caret via the keyboard and having to tap your arrow-keys 4 or 8 times per indent instead of just once.

You spaces-only people are totally spaced out, man.

> I want to arrest any misconception that us Tabbers would do anything as nonsensical as using our precious variable-width tab-stop chars for anything like column-aligning identifiers: we don't.

The irony is that this is exactly what tab characters are used for. Have you wondered why they're called tabs? Because they're used for tabulation, making tables. They are intended for aligning columns in a table. Not for indentation.

I'm so happy that languages like Go have formatting tools that sidestep all these pointless discussions. :)

We aren't using typewriters anymore.

Word processors still use tabs for that purpose.

What ones?

MS Word uses XML in docx.

We were talking about typewriters, which don't have a file format at all. Nevertheless, it might not be stored as ASCII code 9 in Word anymore (though it originally did), but it is entered and behaves like a tab stop on a typewriter, and is called a tab character: https://learn.microsoft.com/en-us/dotnet/api/documentformat....

I personally agree with this, but a lot of the tools out there break this easily. I'm curious if you have any tools that handle the formatting like this properly. I've written my own tool that will report invalid whitespace when following this, but it can't fix any of it automatically. The commonly used clang-format also messes up this scheme as it will convert alignment space to tabs.

I'll admit that I spend most of my time in Visual Studio which supports my preferences very well, including my .editorconfig (which is now the .editorconfig for my entire org... it's almost as if good ideas have a following ;)

I do understand the appeal and advantages of having automated+opinionated re-formatting as part of a gated check-in process, because it's about having a normalized and consistent representation in the canonical repo; the idea being that you'd have a git-hook that would apply your own preferred formatting style on checkout which would be undone on commit; alas, we're not quite there yet.

...but having a single, normalized format (even if everyone hates it for different reasons) is the reason why gofmt and clang-format stick to spaces. I remember (back in 2017) being forced to submit to gofmt's dominion over my code and it ruining my beautifully aligned mass-assignments - and in my frustration I complained about this on StackOverflow and almost immediately someone replied with a working solution: use C-style comments to "protect" whitespace from being mangled by gofmt, see here: https://stackoverflow.com/questions/46940772/how-can-i-use-g...

Also, apparently clang-format now supports tabs with some hoops: https://stackoverflow.com/questions/69135590/how-make-clang-... - does that work for you?

I'm mainly in Visual Studio at my job as well, I was more asking for my personal projects since at work the issue has been "solved." Sadly the clang-format stuff doesn't work, while it looks like it supports tabs on the surface all those settings do (at least last I used it a year or 2 ago) is convert all of the tabs to spaces, do all the formatting it typically does, and then convert all x number of spaces back to tabs if they're at the beginning of the line. Effectively converting all the alignment spaces to tabs (leaving a few spaces at the end if it's not an even multiple.)

My tool at this point basically just has a bunch of rules like,

  1) if tab indentation changes, spaces for alignment aren't allowed
  2) tab indentation can never be off by more than 1 of the prior line

Also flags cases of trailing whitespace and I believe tabs not at the beginning of a line. Still debating how I'd like to handle fully spaced files as my current program reports no errors in that case, maybe just throw a warning somewhere that the file looks suspicious.

Sir, you are way out of alignment. Detabulate immediately.

My style using spaces is

  some_func(
      eyesore,
      blah
  )

which would work just as well with tabs.

Many years ago, I used tabs, and set them to two-space indent. The former because the entire point is that tabs carry different semantic information - this is a level of indentation, not just making things align vertically - and allow each developer to set the indentation width to their preference. (The other comment from DaiPlusPlus explains the proper use of tabs, just as I did it.)

The latter because that makes them more square. Aesthetics matter.

I switched mostly out of peer pressure. But one argument I did find convincing is that setting some specific limit on line length - whether it's 72 or 78 or 80 or 100 or anything else - makes sense, and letting people change the amount of indentation defeats that purpose. That is: the guy who likes 8-space indents can't actually have them, because it produces a horizontal scroll for code that "conformed to the style guidelines" when written by the 2-space guy.

But now I alias names, break up complex subexpressions etc. to avoid questions of how to split code across multiple lines - and most lines in my code are nowhere near any such length limit. And I write short functions, so there aren't enough levels of indentation to matter.

And I use 4-space indents, because standards have value after all.

We use 4-wide tabs and in our code style it would be

    some_func(
        verylongarg0,
        verylongarg1
    );

Which I feel is the most readable option. If you have to break the args into a vertical list, you want to use the least amount of whitespace before each arg. It's also a bit easier to read with every term starting at a tab break.

that's the entire point of tabs, they can be customized to what the person reading them wants. It's an accessibility issue (https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...).

Both tabs and spaces can in principle behave any way a user would want in editors, at least for whitespace at the start of a line. In particular, an editor could have (suitable ranges of) spaces behave like tabs, or vice versa. However, almost no editor provides the full range of desired behaviors for both. For example, one thing I don’t like about tabs is that cursoring over them makes the cursor jump, and not proceed at constant speed horizontally. An editor could in principle have an option to not do those jumps, but barely any editor has.

Not agreeing on width is an argument in favor of tabs.

That’s not invariant under refactor-renaming the function name.

An invariant way of keeping the arguments clear of the function name would be:

    with_long_func_names
    (
        this_scheme,
        looks_muddled
    );

Though it would take some getting used to intuitively recognizing that as a function call.

The beauty is you don’t have to.

I would agree that there aren't any arguments for spaces and would be 100% on the side of tabs, except for one problem: variable width means you can't enforce a maximum column limit.

Some people don't care about column limits, but they're important to me because I like to tile multiple editor panes side-by-side with no space wasted.

The entire debate is stupid anyway and should already be a solved problem. If we used tooling that operates on syntax trees instead of source text, then every developer could have exactly the formatting they want without conflicts. I don't know why that isn't more widespread; the only language I know of to do it is Unison.

Why can't you just have a linter or a hook check that (tabs*2 + chars) < $defined_width

Because a coworker might want (tabs*4 + chars) < $defined_width. Whatever multiplier you pick, it will either mean a too short or too long limit, and inconsistent limits between lines depending on how much indented a line is, if everyone uses a different tab size.

Parent comment edited I think,

But I was addressing the the issue if enforcing column widths in a shared code base. I interpreted their statement as something like "you can't enforce column width in a code base with tabs".

But if someone changes their tab width, it's easy to check if it goes over 80, given a standard of 2 space tabs, and they use 1. Is they don't indent enough, that's harder.

I personally reformat code temporarily depending on what I'm doing, column width to me is a publishing standard, I don't care about it while I'm deep in the code.

Before the parent's edit it was about line length limits, IIRC. In any case that's what my comment was referring to. If you want to limit line length to, say, 100 characters (to visually fit within a 100-character wide window or terminal), then it matters what tab width you use. If you check it assuming a tab width of 8, someone working with a tab width of 2 will be limited to shorter lines the deeper the indentation level. Conversely, when the check assumes a tab width of 2, someone working with a tab width of 8 is likely to see lines longer than 100 characters although the lines passed the check.

Well, obviously tabs should always be 8 spaces.

Not sure if you're joking since 8 makes the whole problem even worse :)