[HN Gopher] The Tabs vs. Spaces war is over, and spaces have eme...
___________________________________________________________________
The Tabs vs. Spaces war is over, and spaces have emerged victorious
Author : ChiptuneIsCool
Score : 66 points
Date : 2025-07-25 18:03 UTC (4 hours ago)
(HTM) web link (xn--gckvb8fzb.com)
(TXT) w3m dump (xn--gckvb8fzb.com)
| mjburgess wrote:
| 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 wrote:
| Didn't you read the post? The WAR is OVER. End of discussion!!1
|
| (golang converted me to tabs too)
| wslh wrote:
| Not OP, but the article ends with the following question:
|
| > Is it truly over? ;-)
| smrq wrote:
| "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.
| o11c wrote:
| 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 wrote:
| Really? What standards are they?
| Joker_vD wrote:
| 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/utilitie
| s/t...
|
| [1] https://pubs.opengroup.org/onlinepubs/9799919799/utilitie
| s/e...
| zamadatix wrote:
| 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-r wrote:
| 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.
| whoomp12342 wrote:
| And what say you about reaching a consensus on the number of
| tabs to use?!?!?!
| g-b-r wrote:
| If someone uses more than one tab per level of indentation he
| should be forbidden access to editors for life
| quietbritishjim wrote:
| > 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.
| JohnFen wrote:
| > 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.
| eurleif wrote:
| >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?
| 1718627440 wrote:
| 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.
| quietbritishjim wrote:
| 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.
| arcbyte wrote:
| 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.
| quietbritishjim wrote:
| 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.
| ecocentrik wrote:
| The whole line of thought is just a waste of cycles. /Screams
| "tabs", sticks fingers in ears and walks away.
| DanHulton wrote:
| 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. -\\_(tsu)_/-
| ar_lan wrote:
| > I write code so it is easy to read, and spaces are better
| for that than tabs, so now I use tabs. -\\_(tsu)_/-
|
| This is a very confusing final sentence. :)
| moomin wrote:
| I'd say that one's approaching resolution, too. And 4 has won.
| frizlab wrote:
| I use tab at three. And will do to the day I die.
| ben_w wrote:
| 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.
| PlunderBunny wrote:
| 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.
| 1718627440 wrote:
| 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.
| g-b-r wrote:
| 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.
| rimunroe wrote:
| A friend of mine worked at a place which used three column
| indents and now I'm fully converted
| pmontra wrote:
| 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_Peregrinus wrote:
| 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.
| eikenberry wrote:
| But don't fixed width fonts, which many consider the best for
| code, mean fixed width spaces too?
| em-bee wrote:
| 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.
| barbazoo wrote:
| One or two tabs though?! /s
| phplovesong wrote:
| 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)
| gte525u wrote:
| This works until someone tries to vertically align something
| like a table or a line that is wrapped.
| marssaxman wrote:
| tabs for indentation, spaces for alignment
| skylurk wrote:
| Meanwhile, I'm trying to get away from languages where
| whitespace has semantics.
| PaulDavisThe1st wrote:
| 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.
| fmbb wrote:
| Only a goblin would align code.
|
| But if you must you can start with a new line and the right
| indent.
| gte525u wrote:
| From my experience, it seems to be the people that learned
| PASCAL first for some reason.
| AdamH12113 wrote:
| 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.
| Arelius wrote:
| 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"
| throwawayqqq11 wrote:
| 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.
| camel-cdr wrote:
| Disallowing /[^\t]\t/ and /^ / is a good start.
| ytpete wrote:
| 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.
| bigcojosh wrote:
| https://nick-gravgaard.com/elastic-tabstops/
| Arelius wrote:
| 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"
| mananaysiempre wrote:
| 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
| jahewson wrote:
| 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.
| fsmv wrote:
| This problem is solved by gofmt because it automatically
| aligns with spaces after the tab so humans don't mess up the
| whitespace
| jedberg wrote:
| 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.
| PaulDavisThe1st wrote:
| > 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).
| jedberg wrote:
| 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.
| PaulDavisThe1st wrote:
| It seems that you don't understand what a tab character
| is ...
| jahewson wrote:
| 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.
| rkomorn wrote:
| 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?
| vouaobrasil wrote:
| 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.
| frizlab wrote:
| Until you are visually deficient. Then it matters a lot.
|
| Accessibility is not a joke.
| vouaobrasil wrote:
| That is a good point.
| IncreasePosts wrote:
| It seems problematic to have a single character in the entire
| universe for characters render as variable, user controlled
| width.
| TheAceOfHearts wrote:
| 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 wrote:
| 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...
| throwawayqqq11 wrote:
| 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.
| lesuorac wrote:
| 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.
| rafram wrote:
| 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.
| lesuorac wrote:
| 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.
| g-b-r wrote:
| > 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?
| thih9 wrote:
| > 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.
| Izkata wrote:
| 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.
| thih9 wrote:
| > 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?
| geon wrote:
| Stop aligning stuff. I don't even use a monospaced font.
| g-b-r wrote:
| Yeah, let's just give up on readability
| 1718627440 wrote:
| That's on you though, in the editors I use they are visible
| and not just in my default IDE.
| xipix wrote:
| 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.
| idbehold wrote:
| I can and do assume a monospaced font when using spaces to
| align code. Folks using variable width fonts will get what
| they deserve.
| deafpolygon wrote:
| 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.
| throwawayqqq11 wrote:
| But this depends on the identifiers you choose. Languages
| cant help here, or better should not.
| vbezhenar wrote:
| https://www.reddit.com/r/ProgrammerHumor/comments/1sq7sp/tab.
| ..
| tsss wrote:
| If Rob Pike is pro-tabs I ought to seriously consider that the
| spaces people were right all along.
| frizlab wrote:
| I don't like go, but at least they got that right!
| vvillena wrote:
| Funny that the language famous for enforcing standard
| formatting allows freedom for this one particular thing.
| suralind wrote:
| It is standardized tho. Tab width in the editor is a
| preference just like the theme or a font each dev uses.
| personjerry wrote:
| Wait until you guys hear about fibonacci tab spacing:
| https://marketplace.visualstudio.com/items?itemName=ewic.fib...
| jedberg wrote:
| 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 wrote:
| 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."
| o11c wrote:
| 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.
| IncreasePosts wrote:
| Indentation is alignment
| microflash wrote:
| Indentation is columnization.
| sergiotapia wrote:
| Just gimme a `go fmt` or `mix format`. These discussions are so
| 2007! :)
| cesaref wrote:
| I remember these discussions in the 80s...
| taeric wrote:
| 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 wrote:
| 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.
| frizlab wrote:
| 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.
| arccy wrote:
| learn some vim based movement, jump to the next non space
| character.
| tinco wrote:
| 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?
| chrisweekly wrote:
| 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.
| PaulDavisThe1st wrote:
| 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-r wrote:
| Exactly, just have your linter error out if there's a tab
| following a space
| Etherlord87 wrote:
| 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).
| hackthemack wrote:
| 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.
| frizlab wrote:
| Navigation is still more painful with spaces than with tabs.
| DrSiemer wrote:
| Not if you learn to use the right shortcuts for it
| (ctrl+arrows, mostly).
| bbkane wrote:
| 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_thibedeau wrote:
| An autoformatter wont touch a tabbed ASCII diagram in the
| comments,
| arccy wrote:
| 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.
| GeorgeTirebiter wrote:
| 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.
| Izkata wrote:
| 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.
| frizlab wrote:
| I have used tabs with a three-space width since forever, and it
| is indeed the better spacing.
| notarobot123 wrote:
| 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 wrote:
| 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.
| PaulDavisThe1st wrote:
| LLM? Emacs has been doing this for decades without any such
| technology.
| throwawayqqq11 wrote:
| 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 wrote:
| Just define Tab as 1 space, and they can be used interchangeably.
| Peace in our time.
| patrickmay wrote:
| You are a monster. I would like to buy you a beer.
| tfandango wrote:
| he only drinks Tab.
| sidewndr46 wrote:
| Why stop there? The tab nihilist would just define the tab to
| be 0 spaces. Then, tabs do not even matter
| em-bee wrote:
| they still would in python.
| IncreasePosts wrote:
| Not if they're inside a string
| purpleidea wrote:
| 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 wrote:
| >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.
| deafpolygon wrote:
| 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 wrote:
| Thankfully all the go code I'm working with has tabs.
| TheAceOfHearts wrote:
| 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 wrote:
| 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 wrote:
| Bullshit. Tabs are the only sane choice and I don't care what
| anyone else says.
| indycliff wrote:
| What would an LLM choose... guarantee it's a tab
| jahewson wrote:
| Tabs are for _tab_ les. Change my mind.
| jfengel wrote:
| 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 wrote:
| This is yet another reason why source code sb stored in parsed
| AST form.
| exiguus wrote:
| 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 wrote:
| 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 wrote:
| The fact that Go = tabs is just one more good reason to use it,
| in my book.
| tfandango wrote:
| My favorite things about the Tabs vs. Space war is that you can't
| even reference it without igniting it.
| ChrisArchitect wrote:
| Obligatory Silicon Valley HBO clip on Tabs vs Spaces:
| https://www.youtube.com/watch?v=oRva7UxGQDw
| timbit42 wrote:
| Oh great. Now you've restarted the Windows, Mac, Linux wars.
| Quitschquat wrote:
| How about flexi spaces? Best of both worlds. Set you space size.
| DrSiemer wrote:
| 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-r wrote:
| If you enforce a specific width it's dumb to use tabs, just use
| spaces
| binary132 wrote:
| 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.
| dusted wrote:
| 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.
___________________________________________________________________
(page generated 2025-07-25 23:01 UTC)