The Tabs vs. Spaces war is over, and spaces have emerged victorious

https://xn--gckvb8fzb.com/tabs-vs-spaces-the-war-is-over/

by ChiptuneIsCool • 12 months ago

113 230 12 months ago

mjburgess2• 12 months ago

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.

boomskats• 12 months ago

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

(golang converted me to tabs too)

wslh• 12 months ago

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

Is it truly over? ;-)

smrq• 12 months ago

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

o11c2• 12 months ago

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.

maccard• 12 months ago

Really? What standards are they?

Joker_vD• 12 months ago

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

zamadatix• 12 months ago

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.

g-b-r13• 12 months ago

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.

eviks5• 12 months ago

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.

whoomp123422• 12 months ago

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

g-b-r13• 12 months ago

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

quietbritishjim3• 12 months ago

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.

JohnFen2• 12 months ago

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.

arcbyte• 12 months ago

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.

ecocentrik• 12 months ago

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

citrin_ru• 12 months ago

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.

DanHulton• 12 months ago

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. ¯\_(ツ)_/¯

ar_lan• 12 months ago

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

hulitu• 12 months ago

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 ?

moomin• 12 months ago

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

frizlab9• 12 months ago

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

pmontra• 12 months ago

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.

SAI_Peregrinus3• 12 months ago

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.

eikenberry2• 12 months ago

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

em-bee6• 12 months ago

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.

eviks5• 12 months ago

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

barbazoo• 12 months ago

One or two tabs though?! /s

pabs3• 12 months ago

The right number of spaces to use is one.

birn559• 12 months ago

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.

conartist6• 12 months ago

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

mjburgess2• 12 months ago

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

Ferret74462• 12 months ago

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

msgodel• 12 months ago

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.

phplovesong5• 12 months ago

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)

gte525u2• 12 months ago

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

marssaxman• 12 months ago

tabs for indentation, spaces for alignment

fmbb• 12 months ago

Only a goblin would align code.

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

AdamH12113• 12 months ago

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.

Arelius2• 12 months ago

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"

bigcojosh• 12 months ago

https://nick-gravgaard.com/elastic-tabstops/

mananaysiempre3• 12 months ago

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

fsmv• 12 months ago

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

phplovesong5• 12 months ago

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

jedberg3• 12 months ago

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.

PaulDavisThe1st5• 12 months ago

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

phplovesong5• 12 months ago

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.

vouaobrasil2• 12 months ago

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.

frizlab9• 12 months ago

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

Accessibility is not a joke.

IncreasePosts4• 12 months ago

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

pepa659• 12 months ago

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

TheAceOfHearts2• 12 months ago

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.

jihadjihad• 12 months ago

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

throwawayqqq114• 12 months ago

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.

lesuorac2• 12 months ago

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.

thih92• 12 months ago

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.

xipix• 12 months ago

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.

deafpolygon2• 12 months ago

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.

vbezhenar• 12 months ago

https://www.reddit.com/r/ProgrammerHumor/comments/1sq7sp/tab...

pepa659• 12 months ago

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.

frizlab9• 12 months ago

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

vvillena• 12 months ago

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

suralind• 12 months ago

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

personjerry• 12 months ago

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

jedberg3• 12 months ago

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.

hotsauceror• 12 months ago

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

o11c2• 12 months ago

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.

IncreasePosts4• 12 months ago

Indentation is alignment

microflash• 12 months ago

Indentation is columnization.

sergiotapia• 12 months ago

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

cesaref• 12 months ago

I remember these discussions in the 80s...

taeric• 12 months ago

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.

the_mitsuhiko• 12 months ago

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.

frizlab9• 12 months ago

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.

arccy2• 12 months ago

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

tinco2• 12 months ago

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?

ben-schaaf• 12 months ago

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.

chrisweekly• 12 months ago

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.

PaulDavisThe1st5• 12 months ago

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.

g-b-r13• 12 months ago

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

throw-the-towel• 12 months ago

The correct rule is: you shouldn't align.

TZubiri3• 12 months ago

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

Etherlord87• 12 months ago

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

lioeters• 12 months ago

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.

112233• 12 months ago

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.

hackthemack• 12 months ago

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.

frizlab9• 12 months ago

Navigation is still more painful with spaces than with tabs.

DrSiemer4• 12 months ago

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

efilife2• 12 months ago

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

bbkane• 12 months ago

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.

kevin_thibedeau2• 12 months ago

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

arccy2• 12 months ago

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.

justinclift• 12 months ago

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

GeorgeTirebiter• 12 months ago

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.

Izkata2• 12 months ago

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.

frizlab9• 12 months ago

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

RGBCube2• 12 months ago

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.

rossant• 12 months ago

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.

notarobot123• 12 months ago

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.

jl6• 12 months ago

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.

PaulDavisThe1st5• 12 months ago

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

g-b-r13• 12 months ago

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.

kelseyfrog• 12 months ago

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

throwawayqqq114• 12 months ago

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?

ta8645• 12 months ago

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

patrickmay• 12 months ago

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

tfandango2• 12 months ago

he only drinks Tab.

sidewndr46• 12 months ago

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

em-bee6• 12 months ago

they still would in python.

IncreasePosts4• 12 months ago

Not if they're inside a string

purpleidea• 12 months ago

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.

devnullbrain• 12 months ago

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.

deafpolygon2• 12 months ago

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.

konart• 12 months ago

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

TheAceOfHearts2• 12 months ago

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.

Avshalom• 12 months ago

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.

_hao• 12 months ago

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

indycliff• 12 months ago

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

jahewson4• 12 months ago

Tabs are for tables. Change my mind.

kmbfjr• 12 months ago

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

jfengel• 12 months ago

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.

owlstuffing• 12 months ago

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

exiguus• 12 months ago

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

dimava• 12 months ago

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

jeffrallen• 12 months ago

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

tfandango2• 12 months ago

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

ChrisArchitect• 12 months ago

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

timbit42• 12 months ago

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

pepa659• 12 months ago

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

Quitschquat• 12 months ago

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

DrSiemer4• 12 months ago

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.

g-b-r13• 12 months ago

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

DrSiemer4• 12 months ago

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

binary132• 12 months ago

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.

dusted2• 12 months ago

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.

g-b-r13• 12 months ago

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.

dusted2• 12 months ago

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.

alexk6• 12 months ago

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/

tabs_or_spaces• 12 months ago

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

Brajeshwar• 12 months ago

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

wormius• 12 months ago

commas.

em-bee6• 12 months ago

em-dashes

wodenokoto• 12 months ago

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!

donatj• 12 months ago

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.

burnt-resistor• 12 months ago

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

TZubiri3• 12 months ago

I didn't hear no bell

cowboylowrez• 12 months ago

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.

hiAndrewQuinn• 12 months ago

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.

TrnsltLife• 12 months ago

Tabs are better

The Tabs vs. Spaces war is over, and spaces have emerged victorious

Related Stories