"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.
(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.
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.
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.
This argument fails by default if its not understandable.
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'.
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!).
(*) Tabs only and no hard wraps, only soft wraps.
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. ¯\_(ツ)_/¯
This is a very confusing final sentence. :)
Which is the right thing to do. When did the tab stopped having 8 spaces ?
Realistically tabs are best when you're alone and spaces are better when you're collaborating IMO.
That's how TFA reads to me. Never give up, never surrender.
(golang converted me to tabs too)
> Is it truly over? ;-)
The fact that people choose to reject this does not change the reality.
[0] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/t...
[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/e...
> 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...
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.
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.
Unless you're trying to argue that your code is a tsv file then tabs is the wrong thing to use.
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.
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).
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.
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.
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.
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).
[TAB][TAB][TAB]ShortTypename[SPACE][SPACE]variable_name
[TAB][TAB][TAB]LongLongLongTypename[SPACE]variable_name2
ps. the [SPACE] counts above are illustrative, not accurate.
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.
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.
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.
It's hard to view your opinion as unbiased when you think this is how people indent with spaces.
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.
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.
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"
if (foo) {
» frobnicate(bar,
» ...........baz);
}
But if you must you can start with a new line and the right indent.
Accessibility is not a joke.
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.
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).
Also, any use of hard tabs breaks diffs, which should make tabs a non-starter.
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
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.
Just use tabs!
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.
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.
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.
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.
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.
It doesn't work for indent-sensitive languages like Python, but it works for most of the other major languages.
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.
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.
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.
Are you a superior 4-spacer or is that too much for your weak IDE on that 4:3 screen?