21–30 of 238 posts
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."
Also, any use of hard tabs breaks diffs, which should make tabs a non-starter.
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.
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)
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.
Earlier quoted context omitted.
This works until someone tries to vertically align something like a table or a line that is wrapped.
https://nick-gravgaard.com/elastic-tabstops/
No wonder why spaces "won"
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.
Wait until you guys hear about fibonacci tab spacing: https://marketplace.visualstudio.com/items?itemName=ewic.fib...
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.
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.
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.
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.