The point of the "tab" option is that there is no consensus on the number of spaces to use -- so by using tab, one uses a single character, and allows the developer to determine screen spacing to their comfort.

"Tab" being a live option is a symptom of the war-never-over in absolute spacing degree -- since different people have different eye-sight, eye-strain, etc. constraints, different linguistic familiarities, code-density preferences, and so on.

But an editor can just as well let the user choose what width to display spaces at the start of a line. Nothing forces them to be the same width as spaces in the middle of a line.

But don't fixed width fonts, which many consider the best for code, mean fixed width spaces too?

If that were the case tabs would be fixed width too. But they're not. There's no fundamental reason tabs have to be the only variable-width character.

Tabs would only be variable in the number of spaces uses, but those spaces will be fixed width.

And spaces could be variable in the number of "sub-spaces" used. Each could be say 1/8 of a regular space.

which editor does that? space width is defined by the font, and normally you use monospace fonts. i am unfamiliar with any editor that allows you to choose a different font for spaces. besides, it would only work for indents, it would mess up any alignment of code into columns.

None, but it's clearly possible to add since such handling is already present for tabs in almost any editor. I merely mean that there's no technical restriction.

But this option already exists for tabs that are pretty much built for this purpose. It's like adding a fifth wheel to a car because there's no technical restriction even though 4 work fine

Nope, an editor can do that, but it can’t do it just as well because not all spaces at the beginning are indentation, so then you need to have more complicated rules to differentiate between those cases

Too bad editors can't do something as complex as recognize language syntax. Imagine if we had that feature, then we could do things like syntax coloring.

Sarcasm aside, if your editor can't recognize indentation or adjust indentation according to arbitrary preferences, you really need to update your toolset.

Too bad indeed that your fantasy toolset doesn't exist in reality

> so by using tab, one ... allows the developer to determine screen spacing to their comfort

(Allow me to reply to this age-old argument with the age-old counter argument...)

But you also have to decide at what point to hard wrap each line based on a max line length, and you can only do that based on some choice of tab size. Anyone with a different tab size preference would see the right column wandering depending on indentation level. This invalidates the only advantage of tabs (assuming file size is no longer a concern).

A common retort is that each reader's auto format (or soft wrapping) can sort out the wrapping. But if each coder is going to reformat the code anyway then they get the benefit of choosing their own indentation level regardless of tabs vs spaces.

> But you also have to decide at what point to hard wrap each line based on a max line length

I think that you should not be doing this, for the same reason that you should use tabs. It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer.

But all of this sort of thing is pointless debate these days, when it's pretty fast and easy to preprocess the files to match your preferences prior to editing.

>It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer.

And then have merge conflicts between people who set different hard wrap points? Did you mean to say soft wrap point?

Yes, my mistake.

But you don't hard wrap at exactly the max line length anyway. You wrap at the somewhere sensible near the max line length. This is much more tolerable to size changes in indentation.

That's is a much worse user experience. The slack has to be greater for more-nested lines. In other words, you're really just catering to those who have wider tabs.

The whole line of thought is just a waste of cycles. /Screams "tabs", sticks fingers in ears and walks away.

I dont even understand what youre trying to describe here. What is a wandering right column?

This argument fails by default if its not understandable.

Like if my tabs are 2 spaces and I save a file like this:

   line1 = wrapped
     + to_here_max
   if something:
     another_line
       = some_val
       + other

Of course this is exaggerated, especially because most lines won't be close to max width let alone exactly at it. But you can set the width of your editor to whatever number of columns that you're hard wrapping to (i.e. what you save in the file) and be sure every line will fit.

Then someone else loads it with tab width set to 6:

   line1 = wrapped
         + to_here_max
   if something:
         another_line
               = some_val
               + other

Now the max column width of a line depends on the syntactic indentation level of it! Any width you choose for your editor will either overflow for some deeply nested lines or waste loads of space on less-nested lines.

Of course it's not a real concern because your editor can probably automatically fix this. But if it's clever enough to do that, then the supposed extra flexibility of tabs is actually possible with spaces anyway.

> But you also have to decide at what point to hard wrap each line based on a max line length

Exact and strictly enforced max line length IMHO unnecessary. Too wide code is hard to read, too narrow too but in between there is a wide range of acceptable values. When possible I treat max length as a recommendation, not hard limit.

When you don’t have a hard limit it’s not a problem if code added by someone who uses visual tab width 2 will go over 78 characters in the editor which tab width set to 4. Equally it’s not a problem when someone using 4 will make a line break sooner than one using 2.

I’d say that one’s approaching resolution, too. And 4 has won.

I use tab at three. And will do to the day I die.

Sometimes I remember a workplace system I used, where someone had set tabs to 8 space.

I don't know why it was 8, but it was.

The VAX/VMS terminals we used at university to learn Pascal defaulted to 8 space tabs, on a 80 column screen. That certainly pushed some people towards using spaces.

I use 8-sized tabs with 72 columns in C. The human eye doesn't like moving all that much while reading and more windows fit one the screen even if it is annotated with git blame. In addition there is this argument from Torvalds, that you should mind your maximum nesting in a single function, which I also find useful.

> In addition there is this argument from Torvalds, that you should mind your maximum nesting in a single function, which I also find useful.

Note that nesting is a much bigger issue in a language like C where you have to clean up after yourself, in most languages having a lot of nesting in a function isn't an issue.

It's how they've been interpreted forever on Unix and other old systems

It's probably the main reason why they're so controversial.

Which was influenced by tab stops on typewriters... which were adjustable, but were generally set at 1/2", 3/4", or 1"... which was the equivalent to 5-12 characters, depending on your font (monospaced, but sometimes 10 cpi, sometimes 12 cpi).

A friend of mine worked at a place which used three column indents and now I’m fully converted

According to the table in the article there are more languages with a recommended value of 2 than languages with 4. I'm using 2 for Ruby and 4 for Python. I don't remember what I'm using for JavaScript, maybe the same value of the main language of the project.

You should really use 3 since obviously people want a bit more than 2 and a bit less than 4. I use 3 for that reason, as I was most productive at 3. At 2 I don't get an overview easily enough, at 4 indents start to creep too far out making it hard to work in larger functions. 3 is really the smallest number where I still easily saw the big picture structure of a file, so I feel that is the optimal one, at 2 I start to not be able to eyeball how indented a piece of code is.

Not sure why people are so obsessed with having power of 2 spaces, can anyone explain that? Why argue over 2 vs 4 when you can have 3 for everything? I think 4 is better than 2 since 2 is too hard to track, but 3 obviously is better than 4.

And what say you about reaching a consensus on the number of tabs to use?!?!?!

If someone uses more than one tab per level of indentation he should be forbidden access to editors for life

And now you understand my method of driving nit picky code reviewers crazy! bwahahahahahhaha

Didn't you read the post? The WAR is OVER. End of discussion!!1

(golang converted me to tabs too)

Not OP, but the article ends with the following question:

> Is it truly over? ;-)

I used to defend tabs for this reason, except I kept running into source code formatters/displays online that would attempt to display my code with the tabstop set to 8 spaces, which made it nigh-unreadable.

While I run into fewer that do this nowadays, it still reminds me that with tabs, What I Write May Not Be What You See, which can lead to readability issues, which I feel is a solid enough point against tabs that I've switched.

I write code so it is easy to read, and spaces are better for that than tabs, so now I use tabs. ¯\_(ツ)_/¯

> I write code so it is easy to read, and spaces are better for that than tabs, so now I use tabs. ¯\_(ツ)_/¯

This is a very confusing final sentence. :)

> that would attempt to display my code with the tabstop set to 8 spaces,

Which is the right thing to do. When did the tab stopped having 8 spaces ?

"The war of accessible vs inaccessible is over; 90% of websites don't use ARIA attributes correctly, so the other 10% ought to give up already."

That's how TFA reads to me. Never give up, never surrender.

There absolutely is a consensus: a hard tab is defined as 8 spaces in numerous standards (obviously this only applies to monospace fonts).

The fact that people choose to reject this does not change the reality.

Like what standards, exactly? POSIX in its tabs(1) [0] and expand(1) [1] clearly states that tab stops can be wherever, and "every 8 columns" is just a default.

[0] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/t...

[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/e...

That still wouldn't give consensus on how many spaces people using spaces should use, it would (originally) give consensus on how many spaces a tab was supposed to be.

Really? What standards are they?

The few applications that don't let you configure it are less relevant now, and the alternative to consider tabs of varying lentgh would be to introduce a new spacing character in their place; hardly feasible.

Reality is what people use. Consensus is what almost all people agree on. Standard is just some rule a few people thought would be good to follow.

One or two tabs though?! /s

The right number of spaces to use is one.

The problem with this is: 1. It's relatively hard to think it through to the point that you see and have the potential benefits in all cases(*). 2. All participants and tools must fully support the solution. It needs a momentum it never got so the world settled on a simpler solution.

(*) Tabs only and no hard wraps, only soft wraps.

The war is ending though.

It will be over when we finally format code at read-time so that we respect the viewer's preferences, instead of at save-time to reflect the authors'.

Vertical spacing, ideally, reflects the thought process behind the construction of code: it's semantic.

Read-time revisions to spacing need, only, to change the non-intentional elements of spacing -- indent depth is a very good candidate for this (hence the tab character!).

We already do format code at read-time if you use a decent editor/IDE. You can add smudge/clean filters to Git also.

I personally went through a phase where I compromised by doing one space per indentation level.

Realistically tabs are best when you're alone and spaces are better when you're collaborating IMO.

Rob Pike on why Go is indented with tabs [0]:

> How wide should the indentation be? 2 spaces? 4? 8? Something else?

> By making the indent be a tab, you get to decide the answer to that question and everyone will see code indented as wide (or not) as they prefer.

> In short, this is what the tab character is for.

0: https://groups.google.com/g/golang-nuts/c/iHGLTFalb54/m/zqMo...

Exactly.

Indentation != spacing.

And thats all the argument i need. I dont understand why people argue with consistent text layout for all-spaces. You can use tabs to indent and spaces to align after that, in most cases.

> You can use tabs to indent and spaces to align after that, in most cases.

In practice this is difficult; since the characters are invisible by default, people will inevitably mix up the two. Looks like the industry standard is to give up and use spaces everywhere, unless strict and mandatory tooling exists.

And that was (one of the reasons) why spaces won: alignment always worked.

But the new problem is linters and formatters don't understand alignment, so they always want those extra spaces removed, making a mess.

> linters and formatters don't understand alignment, so they always want those extra spaces removed, making a mess.

I’m not sure what are you referring to, could you give an example?

Stop aligning stuff. I don’t even use a monospaced font.

Yeah, let's just give up on readability

Alignment does not improve readability. Indentation is crucial, alignment is asinine.

> Alignment does not improve readability. Indentation is crucial, alignment is asinine.

What? Well aligning e.g. a long SQL statement is asinine and does not improve readability??

That's on you though, in the editors I use they are visible and not just in my default IDE.

You can't use spaces to align because you can't assume a monospaced font will always be used. You can't use tabs either for that matter. If you need structure, use the language's punctuation and line breaks.

I can and do assume a monospaced font when using spaces to align code. Folks using variable width fonts will get what they deserve.

Really please stop aligning with spaces!

You can use tabs, that’s exactly their role, but only in theory since in practice elastic tab stops that would work with proportional fonts aren’t implemented anywhere in code, only word processors

no, i can't. i want to be able to align on arbitrary columns, not on tab stops. and when i add or remove character that break the alignment, tabs mess everything up. spaces don't.

No, you can't do that with spaces because spaces have a fixed width, which can't always be aligned to a variable width column. Only in the primitive environment of fixed width fonts does this work, but even there the tabstops can also be placed at an arbitrary column position, check Word out

anyone writing code with variable width font deserves the hell they put themselves in.

Sticking to historical limitations can be kind of silly. I used to have a computer with 40-column text display, and I don't feel any need to limit myself to that anymore.

i agree with you on principal, but i am not sure that this is simply a technical limitation. it feels to me more than a simple preference. i can't explain it, but looking at the example in this article: https://storck.io/posts/proportional-programming-code-fonts/ i find the apple systems font example much harder to parse (visually scanning the structure) than the monospace one below. perhaps it is simply what i am used to. but i feel like i am having a more violent reaction than i should have if mere preference and habit were the issue.

perhaps the issue is the specific choice of fonts. the author in that article exclaims that if you allow proportional fonts then any font can be a programming font, while the author of the following claims otherwise and set out to make his own proportional font that is suitable: https://timgord.com/2024-01/lisnoti-a-proportional-font-that... other such projects are https://input.djr.com/info/ and https://go.dev/blog/go-fonts

one issue is that of distinguishing similar characters, which the above projects try to address while some people claim it's not an issue at all: https://alexkutas.com/posts/non-monospace-font

there is also the issue of alignment mentioned in the first article, that can possibly be addressed by limiting font widths multiples of the smallest width.

but there is still the issue of interacting with other programmers, mentioned in this article: https://nelsonslog.wordpress.com/2021/09/12/proportional-fon... we would all have to agree on the same font if there is any kind of alignment needed apart from indentation. right now we can say that you can choose any monospace font, and things will look as intended, but with a proportional font things will look different depending on the font choice. whether that is an issue or not needs further study i think.

more discussion of pros and cons can be found here: https://stackoverflow.com/questions/218623/why-use-monospace...

I definitely do not enjoy the font choice in your first link. The Go font has been pretty good for me. My editor is configured to use "Go" (not "Go Mono"), I don't even notice when I switch from editing prose to editing code.

"Distinguishing similar characters" is just as much of a concern for me when I'm editing technical documentation as when I'm editing source code. Once again, the Go font has served me well. Previously I used some other humanist style font from from the Ubuntu people that had that classic IBM slash-through zero. Some fonts have overly-aggressive ligatures and such, but those fonts should not be used in any technical context, source code is not special.

Alignment is a non-issue because wanting alignment is bad. There, solved that ;-) Arbitrary diff noise over multiple lines because you added one line at the end is a problem, not a goal!

I interact with other programmers just fine. Your linked article seems to be re-engaging in the tabs-vs-spaces flamewar in an era of gofmt rustfmt et al. It's a total non-issue.

Give it two weeks.

You use tabs to delimitate tabular data.

Unless you're trying to argue that your code is a tsv file then tabs is the wrong thing to use.

You use line feeds (\n) to instruct your teletype machine to feed in one more line of paper. Unless you're trying to argue that your text editor is a teletype machine, then line feeds are the wrong thing to use.

I think most people are pretty amenable to the argument that text editors are teletype machines.

Nobody cares that phone calls happen over fiber now instead of telephone lines. So, same should apply to teletype. Nobody is going to care you're reading this over fiber instead of a telephone line.

Now, people do care if they're trying to read a csv document and somebody didn't quote their commas within strings and now the values are in the wrong columns which could've been avoided by using tabs to store tabular data.

> I think most people are pretty amenable to the argument that text editors are teletype machines.

So you're ok if your text editor interprets the LFs of a Unix text file as mere line feeds, without ever going back to the beginning of the lines?

honestly, spaces shouldn't be used; it's a design issue- use tabs only for indentation, then the language should ideally support not having to use spaces for manual alignment.

But this depends on the identifiers you choose. Languages cant help here, or better should not.

I am very much against any alignment with spaces, just not needed, and adding a lot of unnecessary complexity to code formatting. Just use tabs for indentation, and don't mix them with spaces.

I don’t like go, but at least they got that right!

If Rob Pike is pro-tabs I ought to seriously consider that the spaces people were right all along.

Funny that the language famous for enforcing standard formatting allows freedom for this one particular thing.

It is standardized tho. Tab width in the editor is a preference just like the theme or a font each dev uses.

Tabs are the preferred, more efficient and more accessible format, and most people know this. Every golang dev loves just having one tap to indent code, and nobody loves the constant repeat rattle of space indented code.

Seriously though, tabs let you pick what's visually easier for you to read and I've worked with coworkers that struggle when indentation isn't clear.

>nobody loves the constant repeat rattle of space indented code.

It's hard to view your opinion as unbiased when you think this is how people indent with spaces.

The war is mostly over because regardless of it you use tabs or spaces, the many modern languages use a code formatter and reformat to whatever is common. Languages that go with tabs are also now routinely mixing it with spaces for visual alignment and assume a certain tab width for total visual width enforcement.

On the other hand editors often now handle spaces as if they are tabs, even for cursor movement. So well. Both won?

I remember a time when people religiously claimed that both tabs need to be the way to indent but also that they have to be 8 spaces visually. I guess at least that war was lost since now even CSS allows you to change the number of visual spaces a hard tab has.

No one who uses tabs would ever assume a certain tab width for visual alignment. What do you base that slanderous statement on?

I've also never heard anyone argue that someone else should configure some different tab width, is there a specific language ecosystem you were in that had these insane takes?

To quote the linux kernel style guide:

> Tabs are 8 characters, and thus indentations are also 8 characters.

Yes, tabs are used for alignment as well.

To quote the OpenBSD style guide:

> Indentation is an 8 character tab.

The GTK source code uses tabs when the number of spaces for indentation >=8. This goes against their coding-style document, but if you don't have tabs set to 8 you'll find the indentation broken.

git is the same: although it prescribes tabs if you don't set the width to 8 you'll find broken alignment everywhere.

Oh that's terrible. I guess I'm the one that's been living in a bubble. If that's the kind of people fighting the war on our side, no wonder we lost.

This is horrible and goes against the purpose of tabs. You should NEVER use tabs for alignment, only for indentation.

This "broken alignment" only happens when you mix tabs and spaces. If you do not align (with spaces) then all is fine. Please do not align at all, it is too arbitrary and altogether unnecessary.

And yet, navigating the code, you still have to got left-left-left-left to pass the indentation and it’s stupid. Tabs are here, everybody should use them, they are the logical better option, everybody knows it.

learn some vim based movement, jump to the next non space character.

alt-arrow

But it’s not what I mean. When navigating using the arrows it just breaks the flow because suddenly you “don’t move anymore.” Hard to explain, but it is real.

The real war is between people constantly aligning and formatting things in their code and people who just want to know which bits are inside the loop.

Completely agree: tabs FTW. I wish I could find the reference, but when dealing with mono-spaced fonts, readability is apparently enhanced with THREE spaces per indent. Now, good computer people hate non powers-of-two, so it's either 1, 2, 4, or 8 spaces!!!! I guess I'm not a good computer person, because my eyes find tab stops at '3 spaces per tab' just right.

I have used tabs with a three-space width since forever, and it is indeed the better spacing.

I remember suggesting it as a jokey promise over a decade ago, but got curious and tried it myself. It also seems just right to me, and is what I've used in all my personal projects ever since.

I also use 3 spaces myself, because 4 spaces is too damn wide and 2 spaces is a little bit too small. I would use tabs instead, but rustfmt doesn't handle it well at all in some of the nightly options, I've had it use spaces where it should use tabs a lot.

TIL some people use 3 instead of a power of two. I would never had thought of it nor would I have considered it as a reasonable choice. And now I wonder why I would have thought that.

The most important thing is consistency. I've become a huge fan of deferring tabs vs. spaces debates to an autoformatter. Set it; forget it; argue about something else.

This is most useful when applied ecosystem wide - no one in the Go ecosystem argues about tabs vs spaces, they just run `go fmt` (or more likely their editor is set to do that automatically) and move the #$@% on with life :)

Fortunately for me, newer languages tend to include a formatter in the core install/editor tooling - Go, Rust, Gleam, Dart, probably more I'm forgetting... I think Go pioneered this approach and I'm glad others have taken it as well.

An autoformatter wont touch a tabbed ASCII diagram in the comments,

but the autoformatter will have dictated the choice of space vs tabs for the file in question, an likely also the width of tabs (if any) for alignment. so you just need to follow the convention.

The whole point of preferring tabs is so you can customize the display. That can't work if tabs are used in fixed format text.

Go's autoformatter will absolutely screw up existing ascii comments when they randomly decide to change how the formatting works.

As found the hard way when one day we updated the version of the Go formatter, and much of our nice comments needed to be redone. Thanks Go formatter team (yes, that's being sarcastic).

Tabs are better, simply because you can view them as you like. Go obviously does this, and Haxe too (with default formatting options, even tho its configurable)

This works until someone tries to vertically align something like a table or a line that is wrapped.

That’s mostly editor braindamage (that has unfortunately leaked into some otherwise very good codebases, like LuaJIT). Indent things with tabs, align with spaces[1]:

  if (foo) {
  »   frobnicate(bar,
  »   ...........baz);
  }

Both camps will hate you, but things will work just as they should.

[1] https://www.emacswiki.org/emacs/SmartTabs

Actually for me this shows why tabs don’t deliver on their promise. As soon as the user’s tab size is small enough that baz doesn’t need to wrap, the user gets suboptimal formatting. As someone who prefers tabs of 2 and often views code authored with tabs of 4 I encounter this often.

Your team should settle on a maximum line length independent of which tab settings one has

Of course that will always be a compromise, either people who use narrow tab widths or those who use wide ones will have a (slightly) suboptimal experience.

Formatting by hand is probably only going to work for private hobby projects. In 99% of the other cases there needs to be a formatter that does the formatting.

That feels both largely irrelevant and false? False, because there are plenty of large projects that do have a house style but don’t use a formatter at code submission to enforce it—even if you reject the Linux kernel as an atypical example, basically every piece of commercial software from 20 years ago also fits, simoly because both formatters and presubmit checks weren’t nearly as common, and there were some chonkers there (like, I don’t know, Windows XP). Irrelevant, because it’s perfectly possible for a formatter to follow this convention (gofmt does, for example).

Yes, this. Which the counter point is either, Don't align things, or use tabs for indentation, and spaces for alignment.

And maybe you can enforce no alignment, but that's a hard fight to win.

And as far as tabs for indentation and spaces for alignment, I've found no practical way to enforce this via tooling/linting. And a rule without enforcement becomes inconsistent, which is how we get files full of mixtures of spaces and tabs, which is how people get frustrated with tabs, and we decide to throw it all out.

And inevitably, that's part of how spaces "won"

Or dont try to align lines with different indentation levels.

Addind a comment with the right amount of tabs as a table header and align all fields with spaces after the tabs would do the trick.

Disallowing /[^\t]\t/ and /^ / is a good start.

These regexes don't solve what I think is one of the major common problems/complaints though: using extra tabs past the logical indent point as a shortcut to avoid typing so many spaces for alignment purposes.

To take this example from a sibling post:

  if (foo) {
  »   frobnicate(bar,
  »   ...........baz);
  }

Many people will wind up doing this:

  if (foo) {
  »   frobnicate(bar,
  »   »   »   ...baz);
  }

And then your alignment is all messed up if you have a different tabs setting.

Checking for that requires something more like a linter with a detailed understanding of the syntax parse tree.

At some point you just have to flog people ;)

Anyhow, if code reviewers always use tools that highlight the tabs during the reviews, there's a good chance to catch these things.

Maybe you could also have the tab width set randomly at every review, to make these horrors stand out

There are degrees of “detailed”.

For example, I considered writing a small Awk program to check C code in response to another poster’s complaint about lack of tooling, but then quickly came to the conclusion that, with C’s insistence that (say) /??/<newline>* is a valid comment starter, getting this exactly correct probably does need an actual lexer that would go character by character. That sounded like it wouldn’t fit in an HN comment, so I stopped there.

(That said, that’s as far as you’d need to go in the majority of cases. A dishonorable mention is warranted for languages that use the same character as an operator and a paired delimiter simultaneously, that is C++, Java, C#, TypeScript, and Rust with their abuse of the less-than and greater-than symbols, because that would in fact require a parser. In C++ especially, you’ll need full semantic analysis with template expansion, name resolution, and consteval evaluation. Because C++.)

Yet you probably don’t actually need to be that accurate, do you? The majority of syntax highlighters aren’t, and they are still useful. You can usually afford to say that code that perverse deserves to lose, and in return I expect you should be able to gain a fair amount of language independence, which could be worth the tradeoff.

So instead of checking if things are aligned with what they should be, you would just check they are aligned with something, like a left word boundary preceded by a delimiter, and so on. I can already see unpleasant corner cases after thinking about it for a few minutes, but it doesn’t look hellish yet, it looks something like you could experiment with over a weekend to see if it was viable.

It would be crazy that spaces would have "won" because of the silly idiosyncratic alignment that some people seem to like and then teach to others for many decades.

This problem is solved by gofmt because it automatically aligns with spaces after the tab so humans don't mess up the whitespace

Great, so now I need a special editor plugin, and a compatible editor just to be able to properly view code?

No wonder why spaces "won"

tabs for indentation, spaces for alignment

Meanwhile, I'm trying to get away from languages where whitespace has semantics.

It's not about semantics at all. whitespace has (virtually) no semantics in C or C++, but there are few programmers who would feel comfortable reading such code without the suggestive hinting that indentation provides.

Very few where you can delete or insert whitespace at will, (even if only in the middle of 'identifiers').

I am fine with a (single) space being an important part of syntax, just don't use more than 1 please.

I use tabs for indentation and spacing for alignment. Tables should be aligned with spaces. A wrapped line can be tabbed up to the start of the previous line and then spaced for alignment.

Only a goblin would align code.

But if you must you can start with a new line and the right indent.

From my experience, it seems to be the people that learned PASCAL first for some reason.

Wheb there i a formatter you should not care. You can rewrite the code if it bothers you.

You can view leading spaces however you like as well. Modern text editors can be configured to display any number of leading spaces as your preferred indentation width. It's not the 1970s anymore, modern text editors easily support something so trivial.

I never bought this argument, because it seems the vast majority of people are fine with viewing tabs rendered as four spaces. And pretty much the default for spaces is four spaces. So I'm starting to think 99% of the world uses 4 spaces and it's the vocal minority that like 3 spaces or 5 spaces viewing for tabs. And in that case, the configurability is rather irrelevant.

Until you are visually deficient. Then it matters a lot.

Accessibility is not a joke.

That is a good point.

Spaces are better, simply because you don't have to worry if another developer is seeing the code different than you.

See, I can do it too. This is why there is an ongoing discussion. Because there is no clear cut answer, just opinions.

At least this article brings some data to the discussion.

> another developer is seeing the code different than you.

but that's the whole damn point ... I like substantively indented code, you prefer minimally indented, we should both be happy (and we can be, by using tabs).

You could certainly make that argument. You could also make the argument that all the developers on a project seeing the same view of the code enhances collaboration and team cohesion, especially if your team does pair programming.

This is often why dev teams have more specific style guides that include things would be considered bike-shedding, like how many spaces an indent is.

It seems that you don't understand what a tab character is ...

Wait, no, if there is an 80 character line limit and you like 4 space tabs but I like 2 space tabs, we’re going to have a problem. My code will exceed the line length on your screen or be forced to wrap prematurely on my screen to suit your preferences.

I'm not at all convinced that an 80 character line limit makes sense on modern equipment.

On punch cards, teletypes, or VGA CRTs? Absolutely. On SVGA CRTs? Probably. On anything modern? No.

Personally I use a 100 character limit. Anything more and the ability to have two editor windows side by side gets impeded upon. The point is, there is a limit.

Eh. If 1 line of code in 500 has a trailing bit of punctuation scrolled off the side for 1 in 8 coders who have chosen to have both narrow windows and wide tabs, that hardly seems like a deal-breaker, but if it is, enforce common settings/standards.

(I'm fully converted to Team Spaces, but I also don't get too wrapped up in treating what seem to be soft limits as hard limits.)

So are we also going to have team themes, team syntax highlighting colors, team fonts, team dark/light mode, team screen resolution, etc?

Why not bikeshed the bikeshedding?

FWIW, team screen resolution is pretty much already there when the company provides the laptops (+ screens).

People run different UI zoom levels with modern laptops and (especially 4K) screens.

Everyone is diffrent, some people might be visually impared, and having a bigger indent helps them out. The opposite also applies.

This if a fallacy. With tabs i can view on indent as 2,4 or even 8 spaces. With spaces i force some preset on the dev, not always a bad thing, bit less flexible.

It seems problematic to have a single character in the entire universe for characters render as variable, user controlled width.

No, that is its exact special purpose. And why have more than a single one??

The choice isn't (tabs) vs (spaces).

It's (tabs && spaces) vs (spaces).

In the real world, there will always be spaces, whether used for indentation or not. Using tabs for indentation inevitably leads to a mix of both - which is, objectively, worse for maintenance and consistency.

the correct rule is: tabs to indent, spaces to align

[TAB][TAB][TAB]ShortTypename[SPACE][SPACE]variable_name

[TAB][TAB][TAB]LongLongLongTypename[SPACE]variable_name2

ps. the [SPACE] counts above are illustrative, not accurate.

Exactly, just have your linter error out if there's a tab following a space

And ever stronger if a space follows a tab..!

That's how you do alignment (in indented parts)

The correct rule is: you shouldn't align.

The code I maintain (Emacs Lisp) follows that rule.

Just imagine pressing the space bar 12 times for each line, or having to use :vimq! to handle that without going crazy

And if people didn't align text, you could still make an argument that people use spaces to separate identifiers or otherwise tokens, therefore it's spaces vs tabs&spaces…

Tabs are for indentation, to align the beginning of the line, later on if you want to align text somehow, use spaces. You probably shouldn't align lines with different indentation (I align rarely so I can't remember ever to do that).

I'm amazed that your comment is the single reasonable take among this entire discussion full of unsupported assertions and opinions.

Having two different invisible characters to represent empty space is objectively worse. Just use space, and the tab key to insert multiple spaces. Simple. Use .editorconfig and a formatter to enforce the commonly accepted standard. Done.

Sadly you still have to make exceptions for Makefile, Go, etc. that expect a mixture of hard tabs and spaces. Otherwise hard tabs are not allowed in the codebases I manage, and are replaced by the formatter.

Not to mention that space is a normal printable character, while tab is a control character, like carriage return. Control characters have very well defined meaning, that is very different in different contexts.

As an example, and I hope this is not a new information for most, in many text terminals it does not mean "advance forward to a multiple-of-8 position", it means "advance forward to next tab stop", and you can arbitrarily set those (e.g. HTS/TSC on vt220)

If tabs or spaces are mandated at editor level, how are you editing Makefile or TSV files?

I really do not understand anyone, who is against having support for any possible indentation, controlled by the user as is necessary for each use case.

Just define Tab as 1 space, and they can be used interchangeably. Peace in our time.

Why stop there? The tab nihilist would just define the tab to be 0 spaces. Then, tabs do not even matter

they still would in python.

You are a monster. I would like to buy you a beer.

he only drinks Tab.

Not if they're inside a string

Tabs are the modern choice, because you can then configure your editor so that for every tab character, it calls an LLM with the buffer contents up to that point, with instructions to generate an appropriate number of spaces that can then be substituted in. You might be thinking 2, 4, or 8, but the LLM will give you the contextually-correct answer.

LLM? Emacs has been doing this for decades without any such technology.

Emacs can let a butterfly flap her wing, causing momentary pockets of higher-pressure air to form, which act as lenses that deflect incoming cosmic rays, focusing them to strike the LLM's memory; the LLM will then report the appropriate amount of spaces.

Configure your ^\s+ width if it's that important?

In the 90s, when I used various text editors like Ultraedit, Nedit, Pico, Nano, Vi, and my co-workers used Dreamweaver, Visual C++, Visual Basic, NetBeans

I was in the "TABs are superior" camp but only for the initial indention of code blocks.

But somewhere along the way, editors added features that let you see invisibles, and let you set up smart tabs so that you could hit tab, but it would interpolate 4 spaces (or whatever you set) into the document, and let you shift+tab back the indention or TAB the indention, but put in spaces.

More importantly, the mass of people who all coalesced on using the same editor in the web development sphere, Sublime then Atom then MS Visual Studio Code, has made it easier to just say "set your editor to do this".

I have changed my mind to using SPACES now because the editor lets me fake using TABS.

Navigation is still more painful with spaces than with tabs.

Not if you learn to use the right shortcuts for it (ctrl+arrows, mostly).

I know the shortcuts. (It’s not ctrl-arrows; ctrl-arrows is to switch Space.)

There are still situations where it’s annoying, mostly when navigating the code using the arrow, moving from one location to another using the arrows, I won’t add a key modifier right in the middle of moving the cursor, it just doesn't make sense.

Switch space? On any Windows OS ctrl-arrows (left and right) move the cursor by word. I don't exactly understand how people work with code or even do text editing without it.

I’m on macOS and it’s alt-space.

Ctrl-space moves the cursor by “words inside words,” e.g. in theBestVariable, will go between “the” and “Best.” However it conflicts with the system ctrl-space that switch space. Not really an issue, because ctrl-shift-arrow will do the same word inside word move, but extending selection. In the end we can select until the desired location is reached, then hit a single left or right arrow to deselect and we’re there.

You are pushing a lot of complexity to the editor here. Whereas with tabs you can uninstall a lot of garbage and link your keyboard directly with the binary representation of your code.

So it's the same as using tabs but you are actually using spaces for no real reason?

Not that one more opinion in this endless war of opinion will matter, nor will it convince anyone, but I genuinely don't see the issue with "tabs for indentation, spaces for alignment."

Every repo that tries that ends up broken. I've looked at a lot of them.

Also, any use of hard tabs breaks diffs, which should make tabs a non-starter.

Indentation is alignment

Indentation is columnization.

Columnization is alignment

The original "tabulator" key was intended to save time and effort aligning text with spaces. With the ubiquity of decent IDEs that objective is unnecessary.

I think there is a reasonable argument about the distinct semantic value of tabs but they introduce a concept that the general public think is superfluous when two spaces do the trick.

Words can become obsolete if there are other more commonly understood ways of expressing the same thing. This seems similar.

Thankfully all the go code I'm working with has tabs.

Without tab stops, tabs always fall a bit short.

I'm now vaguely interested in hate making a programming language that relies on tabs and field/record separators. Just to really embrace the crazy.

This tabs vs spaces nonsense debate has gone on way too long, mostly because people cling on to terrible legacy text editors. Any modern text editor should allow you to write a simple plugin to display tabs or any combination of leading spaces as whatever indentation amount you prefer.

Projects should just pick whatever standard is most popular for their given language, and then people can tweak their editors for personal preferences.

If you encounter a lot of code on the web then you might consider writing a browser plugin.

I've always been team Tab. I prefer tabs, even in my CSV (actually, TSV) files. But everyone else has decided this for me and I have begrudgingly adopted spaces. Even though Tabs can be set to whatever anyone wants at no switching cost to anyone else. Imagine if Python used actual Tabs.

Wait until you guys hear about fibonacci tab spacing: https://marketplace.visualstudio.com/items?itemName=ewic.fib...

This is the first I've heard of this, but honestly, I think this would be really good for beginners!

Generally, you shouldn't have all that many indents in your function. Using this would be a good visual clue to a beginner that maybe they need to break out their function into multiple functions.

Now let the battle of how much spaces to use begin!

Are you a superior 4-spacer or is that too much for your weak IDE on that 4:3 screen?

Just gimme a `go fmt` or `mix format`. These discussions are so 2007! :)

I remember these discussions in the 80s...

Bullshit. Tabs are the only sane choice and I don't care what anyone else says.

What would an LLM choose... guarantee it's a tab

Tabs are for tables. Change my mind.

Not only that, just wait until they find out there is a vertical tab.

How about "neither tabs nor spaces, and set your editor to indent according to the syntax rules of your language"?

It doesn't work for indent-sensitive languages like Python, but it works for most of the other major languages.

This is yet another reason why source code sb stored in parsed AST form.

This makes me smile. All the hard work to look up the defaults. Personally I prefer that the CI Workflow enforce whatever is chosen.

Edit: it got fixed, thanks to the author

I think with majority of TypeScript projects using Prettier, 2 is more likely to be the default[0]

The linked page literally says to ignore it [1]

> STOP READING IMMEDIATELY THIS PAGE PROBABLY DOES NOT PERTAIN TO YOU > These are Coding Guidelines for Contributors to TypeScript. This is NOT a prescriptive guideline for the TypeScript community.

4 is a historical thing used as a default for all languages in VSCode [2]

[0] https://prettier.io/docs/options#tab-width

[1] https://github.com/microsoft/TypeScript/wiki/Coding-guidelin...

[2] https://github.com/Microsoft/vscode/issues/41200

Edit: found the TS style guide at https://github.com/basarat/typescript-book/blob/master/docs/... , it should be the correct link

P.S. did send a mail to author hopefully they fix it

The fact that Go = tabs is just one more good reason to use it, in my book.

My favorite things about the Tabs vs. Space war is that you can't even reference it without igniting it.

Obligatory Silicon Valley HBO clip on Tabs vs Spaces: https://www.youtube.com/watch?v=oRva7UxGQDw

Oh great. Now you've restarted the Windows, Mac, Linux wars.

I think that war was also "won" -- depending on your perspective.

How about flexi spaces? Best of both worlds. Set you space size.

Meanwhile, the war on tab width marches on. Back when I got tired of inconsistent tab widths, I simply based my preference on the silly fact that some research showed how developers using two spaced tabs make slightly more money.

Among our team we do not enforce a specific width, but respecting the choice of the original author of a project is required.

Kind of annoying how LLMs will sometimes randomly decide to change tab width.

If you enforce a specific width it's dumb to use tabs, just use spaces

I don't think anybody in our team uses tabs, but afaik you still call it tab width

It's called indentation, and your team apparently uses a fixed number of spaces as chosen by the author.

I would humbly suggest that something like “lines of application code ever written”, or better yet, “source code files evaluated since Unix epoch [or “per second” if you prefer]” is probably a better metric. I think in that analysis, you would find that tabs are more than holding their own.

It's slightly insane that computer programs are still mostly derived from plaintext files.. but what's absolutely insane is that we, the people creating those programs, do so by modifying individual characters in those very same plaintext files..

Yes, text is a good interface medium for exchanging program descriptions between humans and machines.. but it's not a very good medium for storing and exchanging program descriptions from machine to machine, or even human to human.. Humans have opinions, sense of aesthetics, habits, and so on.. some more than others, but still, most people care about at least some part of the.. non-important-to-the-actual-program-compiling stuff, such as casing, indentation, placement of brackes, variable naming and so on.. all stuff that's there for the humans, the compiler don't care what you name your variables.. It's insane that there's no abstraction here..

Just think about how much code we've written to wrangle characters in text files.. formatters, beautifiers, linters, preprocessors, templating systems, lexers, compilers.. It's natural, the amount of development invested in this, and the, honestly, pretty good tooling we have to manipulate those individual characters in files, makes it seem like the only way..

But it shouldn't be.. We should be able to describe programs by typing text, but the text shouldn't be there both for us and for the machine, it should be there only for us, the machine should present text to us, that describes the program, but we should be in control of how that is presented to us, far, far beyond choosing a color scheme in our glorified typewriter emulators. I should be able to tell my programming editor how _I_ want things presented, and that presentation should be a setting in _MY_ editor, not something that has any effect on the program descriptions I'm working with.. Like, the browsers default stylesheet in an alternative world where HTML only described what, and didn't allow the webmaster to overwrite the style. Power to the user.

If I wanted variables to be blue and blinking, and I want the function keyword to be a fire emoji, that's on me, that's just presentation..

We shouldn't have directories with plaintext files as our program storage, we should have dedicated program description files, and we should have dedicated tooling to work with them..

We will never have that.

> variable naming and so on.. all stuff that's there for the humans, the compiler don't care what you name your variables.. It's insane that there's no abstraction here..

You would have variable names not saved? They don't matter for the future maintenance of the program?

You can have most of what you ask right now, the further step most relevant here would be to not indent anything in the saved code; with most languages you're free to do it, and it's feasible to have an editor display it with the indentation you prefer; however it could only make sense if there's no way to have your team agree on an indentation style, there's too many fldownsides with hardly any advantage otherwise.

You're always free to have your editor ignore the spaces and display the code the way you prefer, anyhow.

But it's probably not always possible to deduce how things should be aligned.

of course I would have the variable name saved, but and I'd probably require the to be somewhat unique too, but I'd save them as metadata, and I'd let people decide how they want them presented, for exampled with regard to casing.

For example, a variable holding a.. users actions per second. Say I've set up my editor for camelcase, I'd type in userActionsPerSecond, the editor would save the metadata as user,actions,per,second. Another programmer prefers underlines, their editor presents it user_actions_per_second, and a third user prefers it space seperated, but with a box drawn around it to indicate it's one thing and it's presented [user actions per second] or whatever. I'd maybe add a comment as metadata to the variable too, the comment could easily be shown above the variable, just as it is today, but they can never get detached by someone adding another item between the comment and the variable. Some people would prefer no comments at all, others want them always visible, others want them visible on mouse over.. lots of options.

I know I _can_ have almost all I'm asking for, but the hoops we jump through to get them due to storing program descriptions (source code) as plain text directly, with no really good way to add additional information to it (see the many horrors we have with annotations in different languages, for instance javadoc where comments are abused to embed a different kind of language carrying metadata which is only incidentally coupled to what it tries to decorate).

Instead of doing tricks to separate content and presentation, it should be the default approach.

Our entire infrastructure, grown organically over the past what, 40+ years, arrange itself around individual bytes arranged in text files, arranged in folders.. And I get that thinking this must be the best and final form is easy, because, honestly, software development tooling and infrastructure is some of the best and most solid software ever written, no doubt because it's written by the people using it.

It's not like I've talked with god and come with a list of solutions to problems nobody is having, only that, while I'm not really dissatisfied, I've stumbled into this way of thinking about building programs, it's partly due to some brain damage I must have gotten from learning and thinking about lisp, and while lisp does lots of things wrong, it gave my brain this twist that the models we hold of how to do things can be very different from what we're used to.

I think it's worth at least once in a while, to put some ideas on the backburner and entertain ourselves by imagining other approaches other approaches than arranging individual characters in files, which is the lowest form of computer interaction you can imagine outside of writing bits and bytes directly into memory cells. And it's a bit ironic that as we do this very high-level, high abstraction work that is composing a program, using the most primitive interaction with the machine that's still available through user-programs: manipulation of the arrangement of bytes in files.

If you look at modern development, there's still a fairly noticeable part of it that's centered about ascii-art, either directly by hand, or by instructing the editor to do it, and there's a lot of procedure that's there not to describe programs, but to help derive the programs out of the source texts.

Unison's big idea [1] is that code is stored as content-addressed ASTs in a database.

[1] https://www.unison-lang.org/docs/the-big-idea/

Finally, I've been battling with this for ages!!

I’ve also been tinkering around with AI-Coding assistants, having fun and learning many of the missing steps from my career. As someone who loved to write codes that are well formatted, well named, and well organized, the one thing I hate about AI-Coding is the fomattinig mess. So, the first thing I do now is to set `.editorconfig`[1] and add an instruction as part of the process to respect it.

btw, it still ignores it at times.

Of course, long back, these are also the first things I did so the team can reduce fights and let them choose their own tab-to-space preferences. The other thing was to set up `.gitattributes`[2] early on, specially for those on Windows, to commit the correct attribution when pushing to git.

1. https://editorconfig.org

2. https://git-scm.com/docs/gitattributes

commas.

em-dashes

When I started programming in Python I was all like “why do they even allow tabs?” But now I’m like “why did they ever allow spaces?” Space indentation is only nice if your editor has all sorts of weird logic to handle spaces at the beginning of a line as though they where half or a quarter as many tabs.

Just use tabs!

Hear me out - tabs are better because there is no possibility of invalid indentation state. "Make invalid states unrepresentable" and all that,

If your style rule is 4 spaces, you have 3 invalid indentation levels for every valid one. Even if you only use two spaces half your possible indentation levels are invalid.

The number of times in my life I've been editing a space-indented file in vim on some sshed server and had to count spaces is way too high.

Despite the triumphal declaration, bikeshedding flamewars over superficial minutia will continue because that's human nature.

I didn't hear no bell

I would like to congratulate my fellow space using elite on our complete and total victory. I'm also now considering how to use the now empty spot in the ascii chart, I'm thinking we can use tab as an alternative pipe character as I'm tired of hunting for the existing pipe key with every friggin new keyboard I buy.

One of the best side effects of a space victory is that Tab Separated Values are a much nicer format than Comma Separated Values if you aren't bothering to use a proper library since \t appears materially much less often than , in most datasets of interest. (Which you should but, you know, just in case.) Just my two cents.

Tabs are better