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.
> 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.
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.
> 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.
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.
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!).
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.
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. ¯\_(ツ)_/¯
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.
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.
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
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.
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).
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.
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.
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.
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.
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.
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.
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.
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
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 in principle, but i am not sure that this is simply a technical limitation. it feels to me more than just a preference. i can't explain it, but looking at the apple systems font example in this article: https://storck.io/posts/proportional-programming-code-fonts/ i find it 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.
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 could possibly be addressed by limiting character widths to 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.
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.
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.
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.
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.
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).
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 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?
> 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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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).
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.
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.
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.
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.
> 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.
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.
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.)
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.
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.
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.
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."
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]
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.
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.
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.
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.
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.
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..
> 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.
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.
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.
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.
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.
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.
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.
"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.