It may be an editor feature, but it's a UX anti-feature.
If you are in a system small enough that you only ever have to look at code in a code editor, then this anti-feature won't be a real problem.
If you work in a sufficiently complex environment that displays code across a variety of platforms, tabs will only make working with the code more difficult.
Not really. Most interfaces let you select the tab size or use some sensible default (e.g. 4). If you are using tabs properly it doesn't matter what display size they have.
One odd exception is GitHub which inexplicably uses size-8 tabs by default which is way too big. I can only assume that somebody there is a space zealot and wants to screw up the UX for enlightened tab users.
Those metal things you can see there, those are tabstops. They are called tabstops because when you press the tab key, the carriage mechanically stops at the tabstop.
Tabstops were placed every 8 characters. A tabstop is simply a way to "type" 8 spaces with one keypress.
Github is not the only page that uses 8 spaces for a tab, and it's definitely not inexplicable. The Unix/Linux terminal uses 8 spaces by default if you insert a tab. Vim uses 8 spaces by default if you insert a tab. Python considers a tab to be equivalent to 8 spaces. I'm sure there are a lot of other systems that default to this value.
If you want to control how an indentation looks, use spaces. If you want tabs because the size is configurable and can be adjusted to one's preferences, you can't at the same time complain about "unreasonable configurations" that others use :)
> Tabstops were placed every 8 characters. A tabstop is simply a way to "type" 8 spaces with one keypress.
tabstops were _not_ restricted to 8 characters. In many systems different tabstops were different widths from their predecessor. E.g. your first tabstop might be 20 characters in but all the ones after it would be 8 past their predecessor. Alternately you could vary all of them but that'd look pretty weird.
Thanks, TIL. But 8 was common, right? At least from online sources I was under the impression that typewriter tabstops were the reason for the 8 character default.
When I have to work on N platforms that are constantly shifting, I don't want to spend the overhead and mental effort to reconfigure the ones that can be reconfigured, and eat nameless dread on the ones that can't.
When you view code across dozens of platforms, across dozens of machines, your perspective on "high maintenance config" everywhere changes a bit.
If you can't be effective with default configs, you lose efficiency to config maintenance.
Really, the last thing I want to deal with while I'm triaging some critical issue is dependency management for N code viewers.
The `.editorconfig` file in question actually also instructs GitHub to display source code in your repository with a given amount of spaces-per-tab. Just place the file in the root of your repository:
8 is the standard tab width. That's probably why GitHub chose it. (Why 8? I've no idea. Somebody will be along with an explanation soon enough, I am sure, and you can decide whether you believe it or not. But, whatever, it has been 8 for a very long time.)
To change it from 8, you need the `tab-size` CSS property. This has long been supported by all except IE/Edge.
This can be very neat for responsive design: use tabs for your indentation, and then on large screens use `tab-size: 4` because you’ve got space to spare and four is generally superior to two, and on narrow screens use `tab-size: 2` because you don’t have as much width to play with.
This isn't true, because lining things up visually works differently with tabs than with spaces. (Although, personally, this is why I never visually align code like that, but that's the standard style in many organizations/languages.)
I will never understand why people get so religious about tabs vs spaces, but this is a hill I’m willing to die on: please don’t line things up visually in your source code, beyond standard indentation.
> but this is a hill I’m willing to die on: please don’t line things up visually in your source code, beyond standard indentation.
what's the argument against this? There are many arguments for how it can improve readability and speed up understanding of what you're looking at when you're not familiar with it.
There are some popular coding standards that essentially require it, unfortunately.
My opinion on this is that it's a bad idea in the age where we (finally) have near universal acceptance of source control, because they bloat commits with irrelevant changes in surrounding lines to preserve alignment when identifiers change. Black got it exactly right - optimize for readability and change locality.
It’s brittle and fiddly, and it’s basically the only way to make it impossible to use proportional fonts, which are much more important for readability.
If you feel like it’s useful, you should probably be using an editor with real elastic tabstops instead.
the fact that most editors use mono-space fonts by default and hardly anyone is clamoring for the ability to use proprotional fonts seems to argue against them being particularly important to readability, at least as far as the community seems to be concerned.
re "you should probably be using an editor with real elastic tabstops" ... i don't get what you're trying to say. What does real or fake elastic tabstops have to do with the choice to align code beyond just indentation?
Manual alignment is often used as a poor man’s elastic tabstops.
I think there’s a chicken-and-egg situation with monospaced type and programming. Programming was a thing before digital proportional typefaces were a thing, so some people came to rely on the fixed spacing to treat their source code as a 2d grid rather than a 1d buffer. This in turn made it more difficult to switch over to proportional typefaces despite their advantages, and at some point code == monospaced was just taken for granted. Another issue that comes from mistaking your code for a 2d mosaic is the dogma of dictating a maximum number of characters per line, instead of the more reasonable approach of using whatever expresses the structure of the program most clearly, and relying on line wrapping to make sure it’s all visible.
FWIW I use proportional fonts, and 95% of the time it’s completely unproblematic. Fortunately I rarely work with code that uses manual alignment. It’s usually the occasional ASCII diagram that forces me to temporarily switch over to fixed pitch.
There are configurations for your editor that will allow this, independent of the EditorConfig project.