Tabs are denoted by arrows and I don't like being told what to do! :)

The arrows are not instructions. They're the LHS attacking the RHS. Code is war.

> Tabs are simply inferior to spaces...

I think you wrote this the wrong way around?

Ups, yes. I had it switched originally but then for some reason switched it again. Apparently commenting late at night is not a good idea.

English is a bad convention too but we use it because humans don’t need the theoretically best systems to be productive, they need something good enough. Spaces are good enough, tabs are good enough, and anybody who gets emotionally invested in one vs. the other is wasting time.

Also for blind programmers, tabs are much nicer for a screen reader.

What's the difference between indentation and alignment?

Alingment is leading whitespace that is expected to match the width of some non-whitespace text above, indentation is leading whitespace that is just expected to match all other indentations (* level). When indentation is scaled through editor reconfiguration, alignment should stay the same.

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.

Testimonial: I experienced a significant increase in earnings about 4 months after abandoning tabs for spaces. Cause not known but that’s what happened.

Spaces define by themselves the spacing convention unambiguously, whereas tabs is environment dependent and need other tools like editorconfig to guarantee consistency

Well stated.

No, it's incredibly stupid and is missing the point. You use tabs to not be consistent. So that the crazy js person can have a 2-wide indent and the slightly visually impaired person can have an 8-wide indent without reformatting the entire codebase

Are you visually impaired of have you received or read criticisms of this nature from visually impaired persons? Genuine curiosity, because if this is a matter of accessibility I would vouch for tabs.

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.

Spaces force you to worry how that other dev will see the code. Tabs are semantic - you set the editor to display how _you_ like to see it and that other dev sets the editor to display how he likes to see it.

I've recieved.

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

Thats the point.

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

How do you work with max-char-per-line limits of coding conventions ? Does code you write with tabs as 4 spaces follow the convention but then break on Linus computer ?

I personally use a vertical monitor, in Jetbrains that gets me about 130 characters on a line before scrolling, and in VIM it get me about 125. I'll break a long line into shorter lines if they begin to approach the end, but I'm not strict about it. From what's open right now I do have a few lines that get close, and one that goes over. So what? All my coworkers use horizontal monitors and even with gutters and panels open they're not complaining about my line length - and I've not had a complaint about line length since I've started in this industry in 1999. Back then there were no vertical monitors, it was all 4:3 CRTs.

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.

Is there really a value of a max-char rule these days? Editors can scroll, softwrap and usually do neither as screens are large anyway. A max-indent rule makes sense to highlight when you're nested too deep and should refactor, but a long line of code can either be done based on "this looks unusually long" or a formatter that has a set tabwidth.

The decision to use a character that is 8 chars wide for indentation of a highly nested code was not a brightest idea either.

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.