For your answer search "programmers who use spaces make more money"

This is the exact reason that crime statistics are so crummy, even from anonymous surveys. Very few are compelled to admit to a crime that they haven't been convicted of (and some won't even to admit to that). Or why post-sale NPS scores have a negative bent - you're more likely to respond if you have a complaint.

Spaces are simply inferior to tabs since the latter conveys the meaning of "one level of indentation" while the former does not. It's also better for accessibility and file size. There is not one single logical reason to ever use spaces for indentation, not one.

For some very fucking stupid historical reason someone in the 80s made the idiotic decision of spaces being the default in editors and people just went with it. The people earning more are doing so because those are the seniors who have given up on common sense and just go with the flow of the masses who are unable to grasp "tabs for indentation, spaces for alignment" yet insist on keeping alignment so the (terrible) compromise is just using spaces. And I strongly question whether "alignment" is worth anything, in almost all cases it's just useless and in the rest you're drawing ASCII diagrams in the comments which doesn't affect your code at all.

Also see the top answer at https://www.reddit.com/r/programming/comments/8tyg4l/why_do_...

I think you wrote this the wrong way around?

What I think gp is underestimating is just how much alignment there was in the old days, and how little (compared to now) indentation. From today's perspective, indentation is the norm and alignment is the rare exception. Your question is a good illustration: sounds like you never met alignment, or at least never noticed it. But back then, alignment was a very regular occurrence and the extra diligence required for getting all the tabs and blanks right to look nice on different tab widths, or the ugliness from failing to get the mix right would have been a considerable cost. Avoiding unpredictably wide tabs was a reasonable call.

Thing is that with spaces you can also predict consistently the line length and not have code being clipped on someone's screen that set tabs for 8 spaces for some reason.

In any case, I like spaces but I am impartial to either one. You seem like you have very strong opinions about the matter so I won't push the subject further.

  > Thing is that with spaces you can also predict consistently the line length and not
  > have code being clipped on someone's screen that set tabs for 8 spaces for some reason.

But I'm also the crazy person who uses an 8 wide indent anyway

I like four character width indentation. Linus prefers eight. With tabs VIM shows me what I like and shows Linus what he likes.

As an interesting note, I now work with the second hard-of-sight developer that I've worked with in my life. They both use normal Jetbrains IDEs, with font sizes and interfaces made huge. Neither of them has ever said a word about my line length. Nor my function length. Nor my long variable and method names. Nor my explicit comments, nor my detailed git commit messages, nor my frequent git commiting, nor my branching preferences, nor my README files, nor my obsessive security practices such as validating types and character length limits on input fields and sanitizing and filtering input and my rejecting of any PR with concatenated outside-data in SQL (even if that outside-data came from the DB itself, for a recent example), and all the other idiosyncrasies that one dev suffers from another.

Line length? Not a problem. Forcing the hard-of-sight dev to indent however _I_ see fit? I wouldn't dream of doing that.

I’d love to set up terminal tabstop size, textview tabstop size, github tabstop size, IM tabstop size, HN tabstop size, git gui plugin tabstop size, issue tracker tabstop size, tsv file format tabstop size if I used tabs. It makes you so productive.

Seriously, this takes yak shaving to a whole new level.

To be honest, that's why I love auto formatting cause I never need to think about that stuff, I can just write code.

The real problem is that using spaces for indentation is an accessibility issue.

The solution is to use tabs for indentation, and spaces for alignment.

Not this again

https://github.com/prettier/prettier/issues/7475#issuecommen...

> Blind programmers have no problems with it.

We're struggling with the wrong problem if we aren't asking why the editor can't treat blocks as entities that are displayed however we want.

  > why the editor can't treat blocks as entities

If you have something like:

  var (
    x     = foo
    other = bar
  )

  coolFun(arg1,
          arg2)

  ->coolFun(arg1,
  ->        arg2)

  --->coolFun(arg1,
  --->        arg2)

  ------->coolFun(arg1,
  ------->        arg2)

The problem is when you start doing stuff like:

  if (one) {
  ------>if (two)
             bar();
  ------>else
             xxx(); 
  }

That's what people mean with "don't mix tabs and spaces", not "if you use tabs then the space shall never appear in the file under any condition".

This is clearly false. You said this after giving a perfect example of how it's done with tabs.

  -------->coolFun(arg1,
  -------->------->arg2)

https://superuser.com/questions/710019/why-there-are-11-tabs...

> This is clearly false. You said this after giving a perfect example of how it's done with tabs.

I believe the post you're replying to meant "used more tabs". That is, if you used any tabs beyond the code indentation, they would get altered when you change the indentation size and ruin the alignment.

When I made my original comment I thought what I was replying to was an example of "tabs to indent and spaces to align" immediately followed by a statement that the only way to use tabs is to both indent and align.

Aligning lines in the same block

    ____var a; // indented with a tab
    ____var b; // indented with a tab

    ____var a, // indented with a tab
    ____----b, // indented with a tab, then aligned using spaces

Another alternative is elastic tabs, where tabs are used for both of those, but are converted to an indentation/alignment number of characters semantically. I like the idea, but I've yet to see a good implementation.

Personally I'm a fan of all spaces, but that's mostly because every company I've worked at has used that.

int foobar(int a,

___________int b) // should only ever have spaces (using _ here because HTML)

But good luck finding an editor that won't insert a tab when you use the tab key here (willing to be wrong).

The other issue I have is that diffs break alignment between undented code and anything with tabs because the tabs "eat" the leading space, but unindented lines are offset by one.

I've had some editors that made tab-space conversion an option, but it was never mandatory.

I've not done lots of development with other editors, but Kate didn't do it and the few times I used Visual Studio, it also had similar behaviors (I'm assuming VSCode inherited that stuff).

[1] https://editorconfig.org/

https://lore.kernel.org/keyrings/20221109025019.1855-2-linux...

If HN mangles the link, it is the addition of the `key_create` function in this thread: https://lore.kernel.org/keyrings/20221109025019.1855-2-linux...

https://nickgravgaard.com/elastic-tabstops/

It's the second step that drives me nuts. Why can't/doesn't alignment happen at first step? The inconsistencies of alignment using true tabs, in a monospace plain text environment, grosses me out and decrements my faith in the underlying systems. I appreciate editors w/ settings like `insert spaces when pressing tab` and `the number of spaces a tab is equal to`.

The problem of leading spaces not changing their size can be solved through programming.

Those programmers who have such a problem and need leading space to be rubbery, if those programmers are worthy, will solve that problem instead of complaining that everyone should adapt to them.

The use of tabs is detrimental to code bases. Whenever tabs creep in, invariably people use different tab settings and make a dog's breakfast out of the code.

Code exhibits indented sub-structures that are internally indented, but not themselves not aligned to a tab stop, but aligned with something. One kind of example is something like:

  function_name_of_random_length(lambda (a, b) {
                                     if (a < b) {
                                         indented();
                                     }
                                 },
                                 arg2);

So I'm not convinced the problem you're describing should ever happen.

(if you accidentally use a tab in a file that otherwise uses spaces, you get a runtime exception, or vise versa)

So when your team is compiling locally they don’t type check? It only runs in the IDE and during tests?

But I tried my best to make the build have fast paths to minimize the development loop as much as possible.

Even on an absolutely gigantic codebase using tabs or spaces will make almost no difference to build or type-checking times. Building an AST is much more overhead than white space considerations and once it’s an AST tabs or spaces are not included in the running of the code.