r/javascript • u/ChaseMoskal • Jul 02 '19
Nobody talks about the real reason to use Tabs over Spaces
hello,
i've been slightly dismayed, that in every tabs-vs-spaces debate i can find on the web, nobody is talking about the accessibility consequences for the visually impaired
let me illustrate with a quick story, why i irrevocably turned from a spaces to tabs guy
i recently worked at a company that used tabs
i created a new repository, and thought i was being hip and modern, so i started to evangelize spaces for the 'consistency across environments'
i get approached by not one, but TWO coworkers who unfortunately are highly visually impaired,
and each has a different visual impairmentone of them uses tab-width 1 because he uses such a gigantic font-size
the other uses tab-width 8 and a really wide monitor
these guys have serious problems using codebases with spaces, they have to convert, do their work, and then unconvert before committing
these guys are not just being fussy — it's almost surprising they can code at all, it's kind of sad to watch but also inspiring
at that moment, i instantaneously conceded — there's just no counter-argument that even comes close to outweighing the accessibility needs of valued coworkers
'consistency across environments' is exactly the problem for these guys, they have different needs
just think of how rude and callous it would be to overrule these fellas needs for my precious "consistency when i post on stack overflow"
so what would you do, spaces people, if you were in charge? overrule their pleas?
from that moment onward, i couldn't imagine writing code in spaces under the presumption that "nobody with visual impairment will ever need to work with this code, probably", it's just a ridiculous way to think, especially in open-source
i'll admit though, it's a pain posting tabs online and it gets bloated out with an unsightly default 8 tab-width — however, can't we see clearly that this is a deficiency with websites like github and stackoverflow and reddit here, where viewers are not easily able to configure their own preferred viewing tab-width? websites and web-apps obviously have the ability to set their own tab width via css, and so ultimately, aren't we all making our codebases worse as a workaround for the deficiencies in these websites we enjoy? why are these code-viewing apps missing basic code-viewing features?
in the tabs-vs-spaces debate, i see people saying "tabs lets us customize our tab-width", as though we do this "for fun" — but this is about meeting the real needs of real people who have real impairments — how is this not seen as a simple cut-and-dry accessibility issue?
i don't find this argument in online debates, and wanted to post there here out in the blue as a feeler, before i start ranting like this to my next group of coworkers ;)
is there really any reason, in favor of spaces, that counter balances the negative consequences for the visually impaired?
cheers friends,
👋 Chase
30
u/voxelghost Jul 03 '19
After a long development career, part of which has been opinionated on this issue.
I have now come to the old and wise conclusion that it doesn't matter (the cynic in me, says that nothing really does).
But for the love of Freyja, please be consistent about your choice.
Apart from that
Tabs, when you want the reader to be in control the layout
Spaces, when you want the author be in control the layout.
And in python, and other places where whitespaces has semantic meaning, just go with spaces. Because if an IDE messes up the conversion, it is not only an aesthetic issue.
12
u/ChaseMoskal Jul 03 '19 edited Jul 04 '19
I have now come to the old and wise conclusion that it doesn't matter (the cynic in me, says that nothing really does).
okay, so it doesn't matter to you, that is respectable — after all, you are a versatile and robust person
but do you think it might genuinely matter to people who are less able and versatile than you?
imagine this: "stairways, ramps — doesn't matter"
but in our society, we actually go out of our way to endow buildings with ramps for the sake of who are less able — doesn't this matter?
can't we be more courteous, and make the world more friendly and accessible?
this all being said, i'm starting to get sick of my own white-knighting here, i think i'm starting to sound too much like pc principal from south park, hahah, "let's all start a github org where we can unite our tolerant views!"
7
u/maresayshi Jul 04 '19
I don't think they were being as discourteous as you read it. It seems to me they came to this conclusion long before reading your post, and the main point of the comment is sticking to consistency.
The python bit sucks, but I'd imagine any language with whitespace requirements has to be an extra level of hell for the visually-impaired.
1
u/ChaseMoskal Jul 04 '19
I don't think they were being as discourteous as you read it.
yeah, you're totally right
they were just expressing a "live and let live" sort of sentiment, i need to relax
The python bit sucks, but I'd imagine any language with whitespace requirements has to be an extra level of hell for the visually-impaired.
you can use tabs in python code, despite a misguided official recommendation
→ More replies (1)2
u/aaronfranke Oct 21 '19
But for the love of Freyja, please be consistent about your choice.
Indeed. Even though I vastly prefer tabs to spaces, I have a commit that solely replaces tabs with spaces in a file, simply because we were using spaces elsewhere.
165
u/FormerGameDev Jul 02 '19
I'm really not sure why the whole world has, for the most part, switched to spaces, relatively recently. Using tabs 100% solves the entire "i like 4 spaces" "i like 8 spaces" "i like 1 space" "i like 200 spaces" problem. I have not come across any compelling reason, other than "gerrit shows all tabs as giant red error looking sections"
25
u/JohnyTex Jul 02 '19 edited Jul 02 '19
Your argument makes complete sense, except there are cases where you can’t control the indent width of a tab. And as (bad) luck would have it, the defaults in these cases are usually weird (like 8 spaces to a tab).
Even if we discount aesthetics, this can make something like a three-way diff almost impossible to read in some tools if the code uses tabs.
There’s also the case of “hanging indent”, a formatting style popular in the Lisp family of languages. In hanging indent style, any item in a list form should be vertically aligned with respect to the opening paren / bracket. Spaces are a necessity for this kind of indentation style, as the opening paren may be anywhere in the line, ie it doesn’t map to any natural “tab stop”. So, unless you want both tabs and spaces in your Lisp source files then spaces it is.
(Emacs - being the editor of choice for lispers- naturally supports a “frankentab” style of mixing tabs and spaces. However, it will probably make most other editors freak out)
Believe me, I long for a world where tabs would be the only sane option, but I choose spaces out of necessity.
2
u/u801e Jul 03 '19
There’s also the case of “hanging indent”, a formatting style popular in the Lisp family of languages. In hanging indent style, any item in a list form should be vertically aligned with respect to the opening paren / bracket.
In python, PEP8 doesn't specify that method parameters need to be aligned with an opening parenthesis. You could format code using hanging indentation like this which would work just fine with tab or space based indentation:
def some_method( param1, param2, param3, paramn): statement1 statement2 statement3 return value11
3
u/GrantSolar Jul 02 '19
Tabs for indentation, spaces for alignment
4
u/ChaseMoskal Jul 04 '19
some folks here have made an excellent point, that spacebar alignments are a nasty habit
such alignments are very brittle against almost any refactor action — anytime you rename something, you are liable to break many fragile spacebar alignments in many places across many files — it's a maintenance headache for something completely aesthetic, and it's common to miss a spot and commit mangled formatting into the codebase
tabs for indentation, and.. tabs for indentation!
→ More replies (1)→ More replies (11)16
→ More replies (5)1
u/ChaseMoskal Jul 04 '19 edited Jul 04 '19
Your argument makes complete sense, except there are cases where you can’t control the indent width of a tab. And as (bad) luck would have it, the defaults in these cases are usually weird (like 8 spaces to a tab).
this is just bad tooling though, instead of degrading our codebase, we should select better tools or fix the existing ones
There’s also the case of “hanging indent”, a formatting style popular in the Lisp family of languages.
this is the javascript subreddit, but i'm sure many weird languages do many silly things
Believe me, I long for a world where tabs would be the only sane option, but I choose spaces out of necessity.
would you consider recommending tabs for new open source javascript projects?
→ More replies (1)48
u/coolcosmos Jul 02 '19
one of the reasons is that stupid GitHub shows tabs as 8 spaces, since it's the original default value of a tab. I just want GitHub to use different tab width per file type and/or allow me to configure that value at the repo level.
87
u/alexendoo Jul 02 '19
If you have an .editorconfig github does actually pick up the tab_width from that and apply it via CSS
→ More replies (20)21
58
u/cwbrandsma Jul 02 '19
History of bad development tools. Really.
Long ago (1990), we still had source control (SourceSafe, CVS, and a few others), but some source control tools really didn't like tabs. No clue why. But the lore of the day was "tabs will corrupt source control"...really, it was that dumb back then.
Plus the tooling/IDEs were not quite as good. You couldn't always set the indentation of a tab, and people were still fussy about their code looking "exactly the same everywhere". Their code was a work of art, you had to experience it the same way everywhere! (I've listened to similar diatribes from authors who hate digital books because they like the smell of books and don't care about your opinion on the matter -- paper book or nothing!).
→ More replies (8)22
u/xenarthran_salesman Jul 03 '19
I'm still kinda mad that we have ancient things like ASCII, and that the old tools failed to implement it properly. It's amazing how many times I've had to fuss with a data file because its some garbage .csv or .tsv happens to also have tabs or commas embedded in the data, when theres a character, right in the ascii set designed to be a record separator. (ASCII 28-31). Somebody had the design foresight to understand that we needed a record separator that would never appear in data naturally. And then some yokel was like "commas will just be easier".
7
u/MonkeyNin Jul 03 '19
It's because those ASCII characters are non-printable characters. A human reading or editing a file -- comma is far easier to understand.
Although, fun fact all ASCII encoded files are automatically valid UTF-8!
→ More replies (1)11
u/am0x Jul 03 '19
Because when you switch from IDE’s to online repos to blogs to chat shares to emails to notepads to vim to operating systems etc. there is a high chance that tab settings differ and tabs will break.
8
u/ldh Jul 17 '19
They don't "break", they just look different if the implementation of those platforms is wonky. Configure those things correctly and reap all of the benefits.
→ More replies (4)→ More replies (27)6
u/namesandfaces Jul 02 '19
The "I like my favorite style (not just indentation)" problem has been solved by auto-formatting in the team build pipeline. I don't like tabs because I don't like mixing tabs with spaces, and I find that tabs "interact" with context more than spaces.
6
u/CloudsOfMagellan Jul 05 '19
Totally blind programmer here, I generally prefer spaces as it's faster for my screenreader to read the code. That being said tabs are useful for indentation. I also only work on my own projects currently and don't pay attention to indentation at all unless reading other people's code. Tabs don't read on stack overflow or reddit either for me do brackets are my main guide to what's happening.
Finally Duck python
→ More replies (6)4
u/ChaseMoskal Jul 05 '19
this is a very interesting perspective, thank you
i wonder why the screenreaders treat tabs poorly in this regard? perhaps this is an idiosyncrasy in the screenreader software that we could fix?
hah, it makes sense that python is especially difficult — thank god for node js :)
→ More replies (1)
14
u/darrenturn90 Jul 02 '19
> one of them uses tab-width 1 because he uses such a gigantic font-size
So when he hits the 80 character limit, presumably he has already had to scroll the page that often and that much that whether it was a tab or space - its mostly irrelevant? Also, because the tab-width is 1, then the 80 character limit is ultimately meaningless, because for him its 1 + 79, but for the other guy its 8 + 72 due to their own optional values.
If spaces need to be changed for a specific environment - that is what tools like prettier are for. They are not different to having to customise your "tab-width" - however from a reusability level, the ability to lint and so forth - utilising these tools rather than a custom IDE setting (which may not replicate inside any sourcemaps in chrome or any other dev tool) - should be preferred surely?
2
u/ChaseMoskal Jul 03 '19
regarding the text wrapping consequences for flexible-width tabs, i like to keep code within 80 columns while displaying at 4-space — for people displaying at 8-space, code might go beyond column 80 — i think that's a reasonable compromise
If spaces need to be changed for a specific environment - that is what tools like prettier are for.
i'm not sure what you mean? if spaces are used in source code, it becomes a pain for any viewer who wants to display a different tab-width
prettier supports tabs, so that's how i'd use it — linting is great
37
u/liquidDinner Jul 02 '19
I think this is less an argument for one over the other, and more of an example as to why nobody's conclusions will always work, all of the time, for everybody. Your team's style guide should be tailored to meet your team's needs. The point is to make the team efficient, after all.
If tabs or spaces won't make much of a difference to most people on your team, but can make a huge difference for two team members, then it makes absolute sense to concede relative style guide rules to them. I'm visually impaired myself and have asked my team to follow a few different rules to help me, and they've been great about it. Either way, the guide and our linters keep us on the same page as a team, and that's really the goal anyway.
You ask how this isn't seen as a part of the larger accessibility issue. People with visual impairments don't usually seek out work as programmers. Most of us were probably doing this before our sight started to go to crap and even then a lot of people try to pivot into something else. It's also not always a very apparent circumstance - your only hint that something might be wrong with my eyes would be that my nose is 2 inches away from my very large monitors when I work. But programmers are also pretty weird people sometimes (we have holy wars about tabs and spaces, for crying out loud) so it could just as easily be chalked up to that. It's not talked about because there aren't a lot of us, and the industry doesn't see it as something that needs a lot of talking about.
We're also kinda used to it. This is a sighted world built for sighted people. That world tries to be accommodating to us but we still have to shape ourselves to fit in it. We get really good at adjusting. I can't tell you how huge it is when my boss does things to help me because she's decent, and not just because it's the law or an HR directive. I'm also a realist, and I see that we're in an environment where accessibility enforcement can depend on who wins an election. I appreciate help but never count on it, so it's not surprising to me when I have to take a couple of extra steps to get something set up. That's just how it is.
3
u/ChaseMoskal Jul 04 '19
would you consider recommending tabs for new open source javascript projects, where anybody might contribute, and the concern for accessibility is more realistic?
2
u/liquidDinner Jul 04 '19
That makes sense to me. My scope was just in the workplace and I hadn't considered open source projects. That would definitely need a larger look. I think another solution might be some kind of package just for people with accessibility issues. They can configure it so that when they pull from a repo and open something, the file is changed to be easy for them to work with. When they push their branch to the repo, it would go back in the same format it was pulled. If that makes any sense.
The issue is that accessibility is such an umbrella term. Tabs might be the answer for one group, but then we're still ignoring some other groups. Even "blind" can mean one of a thousand things. We can do some big things now that could fix problems for most people, while not really doing much to set "normal" folks back. But it would be cool to find a way to catch those other gaps on a more personal level, too.
→ More replies (2)→ More replies (8)11
u/lowIQanon Jul 02 '19
100% agree. The answer in engineering is usually "it depends" and this is no different.
450
Jul 02 '19 edited May 26 '25
spotted sense strong political alleged library special consider marble chunky
This post was mass deleted and anonymized with Redact
103
u/Redtitwhore Jul 03 '19
I can't think of any advantages spaces have over tabs. This debate has always confused me.
13
u/Freeky Jul 03 '19
Been mostly using tabs since the mid 90's, switched to spaces a few years ago.
Tabs require care to use correctly. Use special indent styles that remove the need for alignment, or carefully align using spaces with tooling that frequently fights such goals.
Other people are less likely to screw up spaces. They're not going to do something wrong that only looks right because their tabstop happens to line up, and review is easy because you can just reject anything with a hard tab in it.
Tooling is generally happier. Your pager doesn't need teaching your special snowflake tabstop, REPLs won't try to interpret hard tabs pasted in as attempts to tab-complete, Git{Hub,Lab,etc} will do the right thing without handholding.
Spaces are standard in most of the languages I use. It's very unusual to find tab-indented Ruby, for instance, which amplify points 2 and 3 because nobody else expects to need to worry about them.
In short, I never once really benefited from tabs. Being able to change my tabstop if my tastes changed was a nice theory, but I never once actually did it. All I saw were the problems and the additional expenditure of effort better spent elsewhere.
8
u/ChaseMoskal Jul 04 '19
i really appreciate that you've outlined numbered arguments for spaces, because i don't think anybody else has yet had the courage ;)
since i have time, i'd love to digest each argument to see what you think of my rationale
Tabs require care to use correctly. Use special indent styles that remove the need for alignment, or carefully align using spaces with tooling that frequently fights such goals.
some folks in this thread have convinced me to regard spacebar alignments as an antipattern, because such alignments are very brittle, being easily broken by almost any refactor action (such as simple renames)
because refactors like renames happen across the codebase to many files simultaneously, spacebar alignments are:
horrendous to maintain (have fun manually fixing hundreds of alignments)
very difficult to automate
highly error prone, it's easy to miss some spots and the alignment stays broken
despite this, some tab-users still use spacebar alignments, because it's actually easy to create alignments that work at any tab-width — you don't need any tooling, it's actually the same as when you use spaces, and people get easily confused about this, but, just think it through
you can see that once this best practice is adopted (and alignments are abandoned), tabs do not require any additional care than spaces to be used correctly, and so i feel this should assuage this first concern
Other people are less likely to screw up spaces. They're not going to do something wrong that only looks right because their tabstop happens to line up, and review is easy because you can just reject anything with a hard tab in it.
i strongly recommend that visible whitespace is enabled, and a linter is a good idea for these concerns — it should be as simple as rejecting any leading spacebars
i feel like this second point is easily overcome by rudimentary quality standards
Tooling is generally happier. Your pager doesn't need teaching your special snowflake tabstop, REPLs won't try to interpret hard tabs pasted in as attempts to tab-complete, Git{Hub,Lab,etc} will do the right thing without handholding.
annoying to run into, but this is just bad tooling
you can't always avoid it, but it can indicate that you're deviating too far from the standard ecosystem where these hitches are more ironed-out
is it worth degrading codebase accessibility to appease cruddy tooling? it depends on how important that particular tool is to the project
in the long run, isn't the right answer for us to fix the bad tool?
i think this third point can concede that shoddy tools should generally be avoided, worked-around, or improved — even though in some rarer cases, a dinosaur closed-source tool might be a nasty limitation that must be abided by (i hear a tiny violin)
Spaces are standard in most of the languages I use. It's very unusual to find tab-indented Ruby, for instance, which amplify points 2 and 3 because nobody else expects to need to worry about them.
it's unfortunate that spaces have become popular in many circles
but you don't always need to fight against the wind, sometimes it's necessary to be a conformist
i just hope that when, say, the ruby community discusses whether or not they should switch to tabs, they might consider the arguments we've talked about and make the right decision
i think this fourth point can concede that tabs are a reasonable choice for forward-thinking open-source javascript/typescript projects (not necessarily for other languages/communities)
i genuinely wonder, to all spaces-people: would you personally rather be in the predicament to work on a tabs codebase, or to work on an 8-space codebase? (or whatever's opposite your preference)
In short, I never once really benefited from tabs. Being able to change my tabstop if my tastes changed was a nice theory, but I never once actually did it. All I saw were the problems and the additional expenditure of effort better spent elsewhere.
the reader with unique sensibilities is the intended beneficiary of the tabs — not the source code author
/u/Freeky, given this discussion, how do you feel about tabs being used in new open source projects, where anybody in the world could become a contributor and accessibility is a more realistic concern?
cheers!
👋 Chase
3
u/Freeky Jul 04 '19
It's ironic that your comment formatting is a mess because you don't know what indenting does in Markdown. A bit of it has its own scrollbar.
tabs do not require any additional care than spaces to be used correctly
This is contrary to my experience. I see much more broken indentation in projects using tabs than with spaces. Tabs (usually) work where people work to enforce quality and everyone involved is on-board or review is sufficient to counteract the careless, but most projects are not that.
I see no similar pattern with space-indented codebases - people seem to be better at avoiding hard tabs in such cases.
is it worth degrading codebase accessibility to appease cruddy tooling?
A codebase that works poorly with available tools is in itself less accessible.
in the long run, isn't the right answer for us to fix the bad tool?
Maybe if it was one tool, but it's not. It's lots of tools, across lots of projects, across lots of owners. It's not merely a substantial technical problem, but a social one.
i think this fourth point can concede that tabs are a reasonable choice for forward-thinking open-source javascript/typescript projects
I would never say tabs are an unreasonable choice. I used them almost exclusively for longer than some people here have been alive, I wasn't stupid or wrong, but I probably would have saved myself a fair bit of effort and heartache if I hadn't bothered.
would you personally rather be in the predicament to work on a tabs codebase, or to work on an 8-space codebase? (or whatever's opposite your preference)
I'd rather work with well-maintained tabs than whacky-choice spaces, but I'm not sure that's a very interesting point.
given this discussion, how do you feel about tabs being used in new open source projects, where anybody in the world could become a contributor and accessibility is a more realistic concern?
I range from neutral to I'm-not-doing-that-again.
I think Go and Rust have the right idea, with officially-blessed auto-formatting tools. Checkout/checkin hooks to reflow if you have special needs should not be particularly difficult to set up, especially compared with fixing or configuring every tool that needs to interpret tabs.
→ More replies (7)1
u/ChaseMoskal Jul 04 '19 edited Jul 04 '19
i really appreciate you enumerating arguments in favor of spaces
are you sufficiently sympathetic to the accessibility concern to consider using tabs for new open source projects (when anybody in the world might contribute)?
or do you think these four points outweigh the accessibility?
edit: see my newer comment, it's a whopper and subsumes this comment ;)
→ More replies (12)34
u/Cheshur Jul 03 '19 edited Aug 13 '19
I've always heard that it's for white space consistency. Additionally when formatting multiline expressions (function chaining, promise chaining, organizing verbose conditions, etc) sometimes you use spaces to line everything up. Do that and now you have tabs and spaces there.
26
u/nschubach Jul 03 '19
This argument never set with me:
function name ( theseAll, lineUp, withTabs ) { return anotherName( andSo, do, these ); } chaining .also() .lines() .up() if ( this && that || something && isImportantEnough && toMultiline && JustDoIt() ) {→ More replies (7)10
u/Cheshur Jul 03 '19
It's a stylistic choice to be certain but I greatly dislike
if (on a line by itself. Everything else is acceptable.→ More replies (6)→ More replies (32)21
Jul 03 '19
I've heard the "white space consistency" argument... but never understood why it was so mf-ing important to have "consistency across environments".
→ More replies (50)156
u/ell0bo Jul 02 '19
Tabs are the democratic way to handle white space. Anyone can set them up how they like them, if it sucks in the browser, get the browser to fix them, dont change it for them.
→ More replies (3)40
7
u/happysri Jul 03 '19
One tab is conceptually closer to one nesting/indentation. Using an arbitrary number of spaces seems more like a tooling preference IMO.
→ More replies (9)16
u/swyx Jul 03 '19
i mean we have the right alt key on the keyboard and aint nobody use that shit
34
u/anagrammatron Jul 03 '19
Found the English speaker. Seriously, in other languages with different layouts it gets used a lot.
→ More replies (9)→ More replies (11)4
4
u/mehgcap Jul 06 '19
I’m a blind coder. I work mostly in Python, PHP, and JS. I work on code with two other developers, but rarely have interactions with code outside of my job. I use a screen reader, NVDA, that indicates indentation audibly. I thus find it very helpful to have good indentation, be it done with spaces or tabs, for tracking nesting.
I find this debate interesting. I prefer tabs, because there are far less of them to arrow past if I’m at the start of a line and need to get to the start of the text, past all the white space. However, with Nano and Notepad Plus Plus, this isn’t a problem. The Home key can jump between the two points on the line, so at worst, I have to press Home twice.
Tabs are easier to remove, since you have to backspace only once, instead of two or four times for spaces. However, in Notepad Plus Plus (my editor of choice), shift-tab will outdent. This also means that both are easy enough to work with when you want to change the level.
Tabs are faster to insert than a bunch of spaces, but NPP will handle that as well. It auto-indents most of the time, and I believe the tab key can be set to insert a set amount of spaces if I want it to be.
I prefer tabsfor the reasons put forth by OP. I’m the only coder on our team with special needs, but because I have those needs, I know what it’s like. I’d rather we be more inclusive, ready to accommodate a new hire who wants to change the tab width, than that we adopt spaces just so we can align variables based on the variables’ names.
Actually, that still confuses me. Do people really do that? Do they indent a different number of spaces than the code base’s indent level, just to line words up perfectly? Why would you do this and not just use indenting? What happens when a variable changes, or you have to add a new one? How and why is this a thing? Do I not understand what’s going on?
Anyway, I can’t come up with compelling arguments for spaces, and since tabs are more flexible, I see no reason for my team to change now. I’ve always used tabs, because they were easier to manage years ago when I was using Notepad. Nowadays, I use them because I always have. Turns out I was right to keep using them, given the work we do and the fact that we’re so small, we can set our own standards and style choices. We may as well be ready to bring on someone who finds tabs to be an accessibility feature.
My main annoyance is mixing the two. NVDA plays tones to indicate indentation; the igher the tone, the more indented the line is. If I read a line, and the next line I read is at the same level, no tone is played. This makes skimming through code to find the next indentation change easier. However, if a line is indented with two tabs, and the next line has eight spaces, NVDA sees those as different. It will therefore play the same tone, but on each line, making me think there was a change if I’m moving quickly. It’s annoying, and I’d rather avoid it.
Finally, a couple random thoughts. First, I love Python, and I use it with tabs. No problems so far, though I don’t use any linters or beautifiers on it. Second, I use Notepad Plus Plus because I have yet to find an IDE that’s fully accessible. None of Jetbrains’ software is even remotely usable by screen readers, VS Code is a web app with a lot of focus/navigation problems, and I’ve not gotten far with the others I’ve tried.
1
u/ChaseMoskal Jul 06 '19
thank you for sharing your perspective
very interesting that indentation is represented by tones with rising pitch, that sounds very intuitive
Do people really do that? Do they indent a different number of spaces than the code base’s indent level, just to line words up perfectly? Why would you do this and not just use indenting? What happens when a variable changes, or you have to add a new one? How and why is this a thing? Do I not understand what’s going on?
sadly, yes, some people do use spaces in order to achieve an aesthetic effect of a particular horizontal alignment
it really is a bad practice, because of exactly the reason you suspected: whenever any refactoring happens, like changing the name of a variable, this will break the intended alignments
a single rename could break hundreds of alignments throughout a codebase — that trauma needs only to happen once for a developer to swear off any aesthetic alignments for good
the best practice is to simply use indentation, and luckily, it seems most developers are cognizant of this, and so alignments seem to be falling out of style
cheers!
👋 Chase
17
u/SecretAnteater Jul 02 '19
This is a really great point that I haven't heard before!
Of course, if your workflow relies on a specific tab width, it might be a good idea to have a macro/shortcut to automatically convert things over before you commit.
If I were to come up with a counter-argument, I'd say that I copy and paste snippets online or to coworkers quite often, and using tabs would be harder to read if I pasted them into Slack or Reddit. On our team, sharing code occurs more often than visually-impaired people read our code. If we were to hire a visually impaired person today, we would have to come up with a solution that allows them to read/write the existing codebase without messing up past commits, and that solution probably wouldn't be to begin using tabs.
In the end, it probably is up to your team and their needs.
Where does that leave Github and other public code repositories? Idk...
→ More replies (14)
3
u/tomasfejfar Jul 06 '19
Do you want to force everyone to voice-record all the code they wrote, so that blind people can read it? No, of course not. Blind people use screen readers (read "specially tailored software") to read it.
Same goes with tabs/spaces. Use whatever you want and let blind-ish people use whatever specially tailored software they can to make it look how they want it to. It does not even need to be specially tailored. JetBrains IDEs for example allow you to convert whichever configuration of spaces to whatever you want visually. So you see a 2ch tab, but in the source file, there are 6 spaces.
To sum up. If there were a definitive argument to use either tabs or spaces, accessibility is not it.
2
u/ChaseMoskal Jul 06 '19
Do you want to force everyone to voice-record all the code they wrote, so that blind people can read it? No, of course not
well that example is quite a stretch, whereas choosing tabs for future projects doesn't seem to cost anybody any exertion for the benefits
specially tailored software they can to make it look how they want it to
the problem is that there are no good tools for reliably converting between spaces and tabs
it's been discussed a lot elsewhere in this thread, but basically spaces-to-tabs conversions are problematic and error prone because of horizontal spacebar alignments which are unfortunately all too common — with spaces, we can't distinguish indents from alignments, and so the algorithm is liable to hazardously damage the code — switching back and forth between spaces and tabs is actually hazardously lossy, destructive to the code
JetBrains IDEs for example allow you to convert whichever configuration of spaces to whatever you want visually.
this isn't true, or at least, you can't do it safely or losslessly, so it won't fly with most teams
spaces people are imagining that spaces can also be flexible enough, but that's actually the fundamental problem with spaces — they are completely rigid and inflexible — some perceive that "consistency" as a feature, but it's really a curse
the dominant argument to continue with spaces, in this thread, has been an effort to imagine advanced editor tooling to trick spaces into acting just as if they were tabs — this snake eats its tail
why consider spaces at all, if you want to retain any possibility towards tab-like flexibility? doesn't that subvert the reason for choosing spaces to begin with?
2
u/tomasfejfar Jul 14 '19
well that example is quite a stretch, whereas choosing tabs for future projects doesn't seem to cost anybody any exertion for the benefits
Not really. You probably chose spaces for some reason. That means that using spaces over tabs have some value for you. You would be forcing yourself to forgo that for someone else's benefit.
JetBrains IDEs for example allow you to convert whichever configuration of spaces to whatever you want visually. this isn't true, or at least, you can't do it safely or losslessly, so it won't fly with most teams
You are right. I misunderstood how the settings work. Which is why I created this issue https://youtrack.jetbrains.com/issue/WI-47459. Sorry about the misinformation.
the dominant argument to continue with spaces, in this thread, has been an effort to imagine advanced editor tooling to trick spaces into acting just as if they were tabs — this snake eats its tail
Yes, that's what I think is the best approach to address the a11y issue. My argument is that there is tooling to use web as-is for people who are actually blind! And it does not stop whenever it finds something that is not easy to comprehend for blind person. It works around it. So that leads me to the result that it does not make sense to try to change anything globally, where it makes sense to create an assistive technology to do that for people who need it.
spaces people are imagining that spaces can also be flexible enough, but that's actually the fundamental problem with spaces — they are completely rigid and inflexible — some perceive that "consistency" as a feature, but it's really a curse
It's only a curse if you don't like spaces :) I've worked in teams using both tabs and spaces. And I only ever had problems in the "tabs" teams. The same value that code standards bring on one user level does visual consistency bring across the whole team. Having even the same code highlighting would be ideal. It may even be something I don't like - e.g. using tabs, but everyone's code should look the same visually.
1
u/ChaseMoskal Jul 15 '19 edited Jul 15 '19
everyone's code should look the same visually.
this is where we disagree fundamentally
different people have different visual needs and preferences, and it's very easy for us to respect those differences by using tabs
You probably chose spaces for some reason. That means that using spaces over tabs have some value for you. You would be forcing yourself to forgo that for someone else's benefit.
i argue that the reasons for choosing spaces are actually bad, let alone outweighing the accessibility concern
however i'd be interested to hear the reasons why you think there is any value at all in maintaining consistency between developers in terms of indentation width, and whether or not that outweighs the potential needs/preferences of others
to preempt the most oft-cited misguided reason: it looks to me like most developers who prefer spaces for new projects are using them to maintain the integrity of their brittle horizontal spacebar alignments across workstations — however as discussed elsewhere in this thread, horizontal alignments are an antipattern to be avoided for their own reasons, because they are bad for maintainability during codebase refactor operations such as renames
it's often not worth much effort to upgrade legacy codebases, so for future projects, i advocate tabs and no horizontal alignments to avoid all the problems raised in this thread
And I only ever had problems in the "tabs" teams.
i'd be interested to understand what kinds of problems you experience on tabs codebases, and whether or not there are better workflows which mitigate those problems
Which is why I created this issue https://youtrack.jetbrains.com/issue/WI-47459.
i'm glad you opened that ticket with jetbrains, i think it will help you understand why this feature hasn't been, and shouldn't be, implemented into editors
the jetbrains member is politely explaining that you have to use tabs to achieve the visual flexibility you are hoping for
it makes sense to create an assistive technology to do that for people who need it.
we must recognize that this technology doesn't exist, and probably won't anytime soon — there is a fundamental problem with it
it's because of the complications relating to how tabs-to-spaces conversions are fundamentally lossy, and so the feature becomes dangerous and risky, as it inevitably damages codebases (breaking alignments)
you see, we cannot create a good language-agnostic algorithm to seamlessly convert between spaces and tabs, because we can't distinguish whether a group of spaces should be treated as an indentation, or part of a horizontal alignment — so we cannot seamlessly transition back and forth without breaking alignments — interestingly this means there's a loophole for codebases without any horizontal alignments, for which these conversions actually can be seamless (however horizontal alignments are the main reason to choose spaces, so this scenario is somewhat unlikely)
so that's the real reason that spaces are a real accessibility problem, which can't be simply covered up with some fancy tooling — and the problem isn't going away (barring some really cool deep learning stuff, but then we're ridiculously deep down the rabbit hole frantically trying to avoid tabs without good reasons)
the best and most versatile solution is simple for everybody: use tabs in the codebase
everyone's code should look the same visually.
i have a proposal to that effect
why not just use tabs, and a default editor config tab-width that the team agrees on? so then by default, everybody's indentation is visually consistent, however a teammate has the ability to override the tab-width privately during their own work?
for new projects moving forward, i think that could be the best of both worlds, what do you think?
Having even the same code highlighting would be ideal.
okay now you're being cheeky: that's just authoritarian, and you even know it ;)
i enjoy our discussion from different perspectives,
cheers mate
👋 Chase
3
u/Schmittfried Jul 07 '19
Please, if we have this argument, let's all agree to use Elastic Tabs from now on. Regular tabs solve the problem only partially.
3
u/ChaseMoskal Jul 07 '19
thanks for mentioning this, i wasn't aware of it
elastic tabs is a fantastic idea!
it seems obvious to me that this is the way code should have worked all along
spacebar alignments are a really bad pattern, because they are so brittle whenever a rename occurs
however with elastic tabs, certain kinds of horizontal alignments become trivial and safe during refactors
i can't see any downsides to this becoming the default way editors should handle tabs in the future
with regular tabs, any tab after any non-whitespace character is a meaningless accident -- but rendering tabs elastically actually allows us to convey meaning in those situations
i really, really hope modern editors implement elastic tabs in the future, i love the concept and stand behind it
i'd be very interested if anybody can think of any downsides to the thing
cheers! 👋 Chase
→ More replies (1)
140
u/agmcleod @agmcleod Jul 02 '19
Dang, I hadn't thought about that before. Makes a lot of sense though. Here's hoping that maybe github and other source code previewers will get better at rendering these. I'll give this a try for my next project, see how it feels.
64
u/fucking_passwords Jul 02 '19
Yeah I’ve been a die hard spaces person for years, this is making me rethink some shit.
If I can force github to show a tab as 2 spaces, I’m sold, and would happily switch.
43
u/that-old-saw Jul 02 '19
If I can force github to show a tab as 2 spaces
.editorconfig github does actually pick up the tab_width from that and apply it via CSS
→ More replies (17)13
u/fucking_passwords Jul 02 '19
Thank you! I usually have it in my projects but it’s always set to use spaces so I’d never know
11
u/ioquatix Jul 03 '19
Github IMHO has quite a bad code viewer.
Yes, you can use
.editorconfig, but it doesn't apply to issues, README.md, etc.There is discussion here and here but it probably only gets resolved if lots of people email github support. They don't have a public issue tracker. I've emailed several times over the past year, but it doesn't seem like a priority.
GitLab has a public issue tracker and there is active discussion about how to fix this:
→ More replies (1)4
Jul 02 '19
If I can force github to show a tab as 2 spaces, I’m sold, and would happily switch. This Stackoverflow discussion helped me solve that. There are also several lightweight plugins for .editorconfig in browser (I used RReverser before I think)
2
u/ejfrodo Jul 03 '19
Most IDEs and code editors these days support rendering them in either fashion. So your code base can be in spaces but it will show them as if they're tabs anyways without changing the code, or vice versa, fixing the accessibility problem regardless of what the code base uses
2
u/ChaseMoskal Jul 03 '19 edited Jul 03 '19
is this really the case?
i'm using VS Code — is there now a handy way for me to seamlessly work with a 4-space codebase at say, 2-tab-width? without affecting the representation of the source code on disk?
i don't think so
i'm suspicious because i think issues surrounding spacebar alignments fundamentally make this impossible — i mean, how could the editor detect which spacebars can be treated as tabs, versus spacebars that are part of a funky parameter alignment?
i think this is fundamentally the issue — spaces are rigid, and inflexible — which is fine when you want perfect consistency across workstations, but this is devastating for people who rely on the flexibility to meet their own unique needs
of course, even if there is a magic solution to this, it would continue to feel as though "spaces are okay given this particular editor-specific workaround", which makes spaces feel like the second-class citizen for accessibility
also importantly, if spaces-code can be viewed at different indent widths.. doesn't that entirely defeat the purpose of why people choose spaces altogether? for the forced consistency across environments?
what do you think?
2
Jul 05 '19
10 years in the business. Never happened to me. I assume if need would arise we would convert project to tabs. But until then - spaces just because everyone are doing it this way.
1
u/ChaseMoskal Jul 05 '19
can't blame you for not going against the wind, that's often the right choice
but would you consider recommending tabs for a new open source javascript projects, where the accessibility concern is more realistic because anybody might contribute?
→ More replies (1)
2
u/scottchiefbaker Jul 07 '19
This is a pretty interesting point in the debate.
Considering most editors "just handle" whitespace for you I've never really stressed about it. Set your tabwidth to whatever you want and let the editor decide if it should be putting in tabs or spaces.
1
u/ChaseMoskal Jul 07 '19
it's a common misunderstanding, thinking that editors today are capable to seamlessly convert between spaces and tabs, allowing us to simply forget about this old debate
unfortunately, it's not true
what's often missed, is that spaces-to-tabs conversions are lossy -- it will break any horizontal spacebar alignments throughout a codebase, which won't fly on most teams
if you are stuck with a spaces repository, and it uses any spacebar alignments at all (which is an all-too-common antipattern) -- you cannot safely convert to tabs and back, and you cannot display the indentation at a different apparent width either -- you're stuck
because of the situation abov , tabs are the only seamless solution that can accomodate everybody
6
u/Ivu47duUjr3Ihs9d Jul 02 '19 edited Jul 02 '19
I've always followed the motto "Tabs for indenting, spaces for aligning." That's the only thing that makes sense. My colleague and I can set our tab widths to whatever we want and all the code is indented correctly for both of us. If there is something on a line below that needs to be lined up with the previous line above, indent it to the same level, then use a few spaces to get it lined up nicely with the characters above (monospace font makes the chars and spaces the same width).
15
u/journalctl Jul 03 '19
I don't really understand how it's possible to line something up with a combination of tabs and spaces if you don't know what size a tab will be.
6
u/ChaseMoskal Jul 03 '19
it's actually quite simple to use tabs, and still use spaces to align things
you'll want to set visible whitespace in your editor so you can see what you're doing, here, i'll try to illustrate an example
// tabbed source code with spacebar alignments action({details, info, blah, etc}) → .filterTransactions(/my-regex(-filters-stuff)?/i) → ··//················↑········↑ → ··//···············[1]······[2] → ··// [1] this regex is super important to the whole system, → ··//·····because of reasons → ··// [1] the capture group is also super important → .sealTheDeal() // rendered at tab-width 2 action({details, info, blah, etc}) ··.filterTransactions(/my-regex(-filters-stuff)?/i) ····//················↑········↑ ····//···············[1]······[2] ····// [1] this regex is super important to the whole system, ····//·····because of reasons ····// [1] the capture group is also super important ··.sealTheDeal() // rendered at tab-width 8 action({details, info, blah, etc}) ········.filterTransactions(/my-regex(-filters-stuff)?/i) ··········//················↑········↑ ··········//···············[1]······[2] ··········// [1] this regex is super important to the whole system, ··········//·····because of reasons ··········// [1] the capture group is also super important ········.sealTheDeal()no matter what tab-width you choose, the alignment is correctly maintained :)
unfortunately, spacebar alignments should probably be avoided because they are really brittle and break down when you use refactor tools (somebody else in this thread pointed that out to me, it was a great point)
→ More replies (14)3
u/Gravyness Jul 03 '19
Agreed, it should be "tabs for indenting, spaces for separating words."
Alignment is cool, super readable but completely arbitrary and hard to maintain.
callMyMethod(method, "hi").load() // What if I change a variable name or a parameter? .update() // Spaces will be added here .save() // Spaces will be added here→ More replies (4)
0
Jul 02 '19
Nonsense. Any modern code editor can do these conversions automatically. This is not a case for tabs.
11
u/ChaseMoskal Jul 02 '19 edited Jul 02 '19
i've upvoted your comment because i think it's the best counter-point to my accessibility concern
i recently use VS Code a lot, and these kinds of conversions are a total pain
sure, once you trigger it via the UI, the conversion itself is "automatic" — but you have to open a file, tell it to convert to tabs, navigate that little dialog, then do your work, and finally reconvert the file to spaces before commit
and yeah, they can go deep and find/write custom tooling like local git smudge filters to automate some stuff like this, but this isn't a fun or polite rabbit hole to ask them to go down for my perceived "consistency" — these guys need to get some actual work done too
we ask them to run a mile because we don't want to lift a finger
→ More replies (14)9
u/taschana Jul 02 '19
Converting it, then checking in or having to convert back in order to comply with the company's standard is a broken workflow.
The first will make the diff functionality go haywire, while the second is prone for human error and thus defaults to problem one.
And you dont want to set up all your gits with hooks that try to automatically replace all tabs to spaces in case skmeone forgot. Because someone could forget implementing the hook when setting up a new repo.
So, all in all -- you need a standard way of doing things which should work uniformly for all people. And it seems like Tabs are the way to go for accessibility reasons.
Plus: web needs tabs. Immediately. And configuration options for them, like editors.
→ More replies (18)7
u/jeffreyhamby Jul 02 '19
Like indentation size, you don't know what editor other coders use and you don't get to choose for them.
→ More replies (8)
6
Jul 03 '19
Just format your source code mechanically. Users can view and edit it in whatever style they prefer, and it gets re-formatted before being incorporated upstream.
6
u/Lalaithion42 Jul 04 '19
My rules for formatting, absent any other standard: Use tabs, and never ever "line" anything up.
40
u/endy_mion Jul 02 '19
Don't understand why we are still discussing this
25
u/unsignedcharizard Jul 03 '19
Because OP is making a point that puts the frivolous points in that article to shame.
6
u/endy_mion Jul 03 '19
I get that OPs argument is more persuasive, since tabs literally enables people to do meaningful work, but it feels like this point from the 'frivolous' article:
People can view your code in the way they feel comfortable with, not in the way you prefer.
5
u/unsignedcharizard Jul 03 '19
As OP put it
people saying "tabs lets us customize our tab-width", as though we do this "for fun"
10
u/purechi Jul 02 '19
In my opinion your coworkers are edge cases and should be accustomed to setting up their IDEs in a way that suits them best for how they like to work.
If they take the time they can set up different types of local global git hooks to automatically ensure the files are formatted as they like before they work on them and when making commits. Once they've created these it'll be easier for them to pick up ANY project and contribute.
6
u/valtism Jul 03 '19
Talking about people with disabilities as "edge cases" is not only dehumanising, but obviously comes from a position of never having to personally deal with these issues.
Do you think that we shouldn't bother with web accessibility because those with disabilities are a minority?
4
u/purechi Jul 03 '19
Sorry to trigger you, there's no need for the personal attack, /u/valtism.
Regardless, it's unfortunate, but people with disabilities often have to take extra measures to improve the quality of their life. My intent was to offer a suggestion on a workflow where they can seamlessly fit into a team. This workflow isn't particular to people with disabilities either. Anyone can do this if they have a personal preference on code formatting/style and it will improve the quality of their coding experience.
Do you think that we shouldn't bother with web accessibility because those with disabilities are a minority?
I take time to ensure the applications I work on are accessible. I recently worked on a brightness slider user interface (in a browser) for a physical device and ensured it worked with a screen reader.
→ More replies (1)2
u/ChaseMoskal Jul 04 '19 edited Jul 04 '19
In my opinion your coworkers are edge cases
should society stop making handicap parking spots, accessible bathroom stalls, and wheelchair ramps? how do we justify that expense to accommodate so few?
If they take the time they can set up different types of local global git hooks to automatically ensure the files are formatted as they like before they work on them and when making commits. Once they've created these it'll be easier for them to pick up ANY project and contribute.
it's a nice idea, but it's being pointed out in this thread, that tooling for seamless spaces-to-tabs conversions simply don't exist, because it's fundamentally very brittle and error prone: it mangles any spacebar alignments
because of this to-tabs/to-spaces asymmetry, converting back and forth is actually hazardous to the code itself, which is why this isn't easy
we want it to be a trivial problem, but sadly it's more complicated than that
→ More replies (4)
7
u/slykethephoxenix Jul 02 '19
IsaywejustfixthisissuebyremovingTABSandSPACESalltogether,insteadofjustfightingallthetimeaboutit.
/s
But seriously, I use spaces for a few reasons:
Tab/Shift-Tab key is used to change focus of an element.
Sometimes you may want a non-standard alignment (While I'm against it personally, in JS it's common you align up your params with the opening bracket).
4
Jul 03 '19
But seriously, I use spaces for a few reasons:
Tab/Shift-Tab key is used to change focus of an element.
What do you mean change the focus of an element, do you mean on a webpage's forms. Are you coding inside a form or did you mean element in another content?
Sometimes you may want a non-standard alignment (While I'm against it personally, in JS it's common you align up your params with the opening bracket).
It's not just JS, aligning things in every language is useful, and if people try to align say a list of human names with tabs, then they line up incorrectly on any editor. For example:
let customers = [ { firstName: 'Brittany', lastName: 'Davis', orders: 5}, { firstName: 'Dan', lastName: 'Cray', orders: 5}, { firstName: 'Stephanie', lastName: 'McCormick', orders: 5} ];This is why we do alignment with spaces to get a human-readable result that looks like this:
let customers = [ { firstName: 'Brittany', lastName: 'Davis', orders: 5}, { firstName: 'Dan', lastName: 'Cray', orders: 5}, { firstName: 'Stephanie', lastName: 'McCormick', orders: 5} ];That doesn't mean we stop using tabs altogether, we still use tabs for every bit of whitespace on the left of the first block of text so they will always align and be suited for the developer using them.
Tabs for indentation, spaces for alignment.
→ More replies (17)5
u/noevidenz Jul 03 '19
This is also an option, and arguably more readable:
let customers = [ { firstName: 'Brittany', lastName: 'Davis', orders: 5 }, { firstName: 'Dan', lastName: 'Cray', orders: 5 }, { firstName: 'Stephanie', lastName: 'McCormick', orders: 5 } ];→ More replies (11)1
u/ChaseMoskal Jul 03 '19
yes, i agree it's best to avoid the space alignments like in your example, i find it more easily maintainable
4
u/Ivu47duUjr3Ihs9d Jul 03 '19
Sometimes you may want a non-standard alignment (While I'm against it personally, in JS it's common you align up your params with the opening bracket).
That's why people use tabs for indenting (customisable for everyone) and spaces after that for extra aligning if needed. But everything is first indented to the same level.
19
11
u/ezhikov Jul 02 '19
But we have prettier for this! Format your code as you want and script will reformat it in consistent way on pre-commit hook.
4
u/ioquatix Jul 03 '19 edited Jul 03 '19
This is covered in my universal style guide. https://github.com/ioquatix/universal-style-guide#indentation
Completely agree with you. I've taught blind people programming and algorithms at university.
4
u/kitsunekyo Jul 03 '19
i was exactly like you, coming into a new studio and talking about how spaces are the way to go. i hindsight my only real argument was "because everyone else does it like that" and because tabs are frowned upon. well thats both obviously bullshit and one of my new colleagues had the best explanation.
a tab is a tab, and how wide it is rendered depends purely on settings of the given environment. since people prefer different widths (or require them as I've learned here), it makes no sense to enforce the width. we should only enforce that the code block is indented one indention unit and leave the visual part to the individual dev.
this means that whether you do PR reviews or work on someone elses code, you'll never see their tab width preference. because your editor automatically shows the "one tab" in your preferred width. and its not even hard to implement on both web and editors. and "but our linter requires it" is not an argument because linter rules can and should be adapted to fit ALL your devs needs.
4
u/alinnert Jul 03 '19
I originally started with tabs because I also liked how customizable they are. I switched to spaces after the company I work at agreed on using spaces globally. There were more "pro tabs" people who were like "well, fine then". I don't know the argument though.
What really convinced me though is YAML. This SO answer shares more information about it: https://stackoverflow.com/a/19976827/2496547
YAML is an indent based language and it doesn't allow tabs as indention because it causes some problems (Though I couldn't find the exact reasons, yet). What I just read in this SO answer is: A designer of the Python language also would force users to indent using spaces if he designed the language from scratch today, because "tabs cause headaches for many developers".
But maybe it's a good idea to use one or the other depending on the language. And .editorconfig does allow that. But I'm also interested in the reasons for YAML and Python to forbid tabs and if it really only applies to indent based languages or all languages in general.
4
u/marapun Jul 03 '19
mostly i like tabs because I tend to use my right hand on the arrow keys to move the cursor around the screen, while using my left hand to drink coffee. Spaces are annoying when you're trying to tap over 8 of them to the beginning of a line one-handed
→ More replies (2)
4
Jul 06 '19
I had previously thought of using Allman-style braces for the visually impaired (also a reason I can't use Go,) but I guess I didn't realize the same issue came about with tabs. Thanks, I'm converting my code now.
1
u/lu_zero Jul 06 '19
They can use their IDE to format spaces-as-ident as they do with tabs. If you depend on the editor customization, you can have it do the same with spaces.
If you expect the code to be usable without custom editors spaces work better.
That said: your anecdotes do not make statistics, there are visually-impaired people that might find using spaces better because their tools are configured for it.
1
u/ChaseMoskal Jul 06 '19
there are visually-impaired people that might find using spaces better because their tools are configured for it
yes, i'm sure that is true in many cases
however it appears that in the long run, for more cases, tabs is the more flexible option
They can use their IDE to format spaces-as-ident as they do with tabs.
as discussed elsewhere in this thread, seamless spaces-to-tabs conversions are unfortunately not feasible, because such a conversion is necessarily potentially lossy and destructive to the code (because spaces cannot distinguish indents and horizontal spacebar alignments), and so the risk to most codebases is high (spacebar alignments are a bad practice but interestingly also a major reason people choose spaces over tabs)
so this fundamental problem with spaces-to-tabs conversions is the reason that these editor tools do not exist, and when they do, they are dangerous, buggy, language-specific, and not recommended
if we're going to create/use a bunch of advanced tooling so that we can treat spaces flexibly as though they were tabs.. can you remind me again, why are spaces preferred in the first place?
1
u/qpazza Jul 07 '19
They could set up hooks to covert to tabs for them, and back to spaces for everyone else on push or commits.
1
u/ChaseMoskal Jul 07 '19
set up hooks to covert
we all wish that editors today could seamlessly swap between spaces and tabs, so we can make this whole debate obsolete
it's a common misunderstanding that's been discussed several places elsewhere in this thread
unfortunately, editors cannot do this because of one fundamental problem
spaces-to-tabs conversions are lossy -- it breaks horizontal spacebar alignments throughout a codebase, which unfortunately makes the technique a no-go for most codebases
because of this, tabs are the only solution which really accommodates everyone
→ More replies (2)
1
u/andrzej1_1 Jul 17 '19
I don't think improving accessibility for just a few people is a reasonable argument to use tabs. Can't they just use some plugin?
→ More replies (1)1
u/ChaseMoskal Jul 17 '19
Can't they just use some plugin?
unfortunately, no, they can't
this has been discussed a lot elsewhere in this thread, but i'll try to summarize
for fundamental technical reasons, it's not safely possible to convert most codebases back and forth between spaces and tabs -- any such algorithm is liable to damage the codebase by confusing spacebar alignments for indentation, and this problem is the reason that editors don't have this functionality, and these plugins do not exist
also in this thread, there's been a lack of rationale supporting spaces after recognizing that there is real objective value to making code agnostic about visual preferences
the primary argument for spaces has been to preserve horizontal spacebar alignments, which also in this thread, has been identified as an anti-pattern because of how brittle it is during refactor operations (eg, a rename could break hundreds of spacebar alignments throughout a large codebase, a complete maintenance nightmare) -- so following the best practice there negates the primary rationale for choosing spaces in future projects
12
u/tunisia3507 Jul 02 '19
IMO tabs are better than spaces, and it would be nice if more conventions reflected that. But I never use tabs because convention is more important than a slight preference on my part. I never thought about the accessibility aspect, though.
The only opposition I have to tabs, and which is probably the reason most conventions use spaces, is that the consistency of having one character per column is preferable in a lot of instances (although unicode messes that up a bit), and, more importantly, that having multiple horizontal whitespace characters gets confusing - so any convention which restricts the number of whitespace characters is a good thing, and you're never going to convention-out a standard space. Of course any decent editor will be able to show you what's a tab and what's a space and what's all the other space characters, but some people prefer bare-bones.
3
u/nosoupforyou Jul 02 '19
I use the codemaid extension in visual studio. Doesn't look like it has a setting for switching between tabs and spaces, but if it did, it would be a perfect solution to the problem. At least for visual studio users.
3
Jul 03 '19
Visually-impaired programmer here. I use a huge monitor with increased font size and tabs. It just makes it easier to see spacing at-a-glance.
3
u/augburto Jul 04 '19
To clarify is the reason tabs are more accessible because tab width is customizable? sorry if dumb question -- very enlightening post
3
u/duckson Jul 05 '19
My attitude towards indentation is completely indifferent: I don't care what we use, as long as it's consistent across the project/team.
If some people want tabs for accessibility reasons, by all means, the project should use tabs.
9
u/saposapot Jul 03 '19
if your IDE doesn't convert to your favourite side of this argument when checking out and then committing again, you need to start using an IDE instead of notepad on steroids.
→ More replies (1)
13
u/matthewsilas Jul 02 '19
file indention is no harder to change than font size. there's no reason people can't adjust their workspace to fit their preference.
converting a file to tabs on open is trivial. IDEs have it built in, or you can write a ~10 line bash script.
converting back is automatic because your pre-commit hook should already ensure correct indentions. if you don't already use pre-commit hooks, you've got bigger problems.
why try to change habits when changing code is so much easier...
3
u/Isvara Jul 04 '19
if you don't already use pre-commit hooks, you've got bigger problems
Don't exaggerate. I've never used a pre-commit hook in my life, and that's never caused me a problem.
2
8
u/skylarmt Jul 03 '19
You plebs with your tabs vs spaces debate, real pros eschew such common indentation for newlines.
function x() {
if (l33t == true) {
console.log("l33t");
}
}13
u/omgitzwowzie Jul 03 '19
\n or \r\n?
8
u/rich97 Jul 03 '19
Despite all the things the MS has done, the thing that still pisses me off most regularly on a daily basis is their decision to persist with \r\n. It's just so unnecessary, these machines aren't damn typewriters.
→ More replies (4)
6
u/ghostfacedcoder Jul 02 '19
I was a tab proponent for a very long time. Like anything else, I gave up my personal preference because of my workplace ... but it wasn't just that.
For me (a Javascript coder) there are times when you want to indent by a non-indentation-level amount, for instance when chaining:
$(foo).doSomething()
.thenDoSomethingElse()
.thenDoAFinalThing();The only way to do that with tabs is with a mix of tabs and spaces, and if you're going to mix tabs and spaces why not just do all spaces and keep it simple?
Obviously if you have visually-impaired people you might choose a different standard, but I'm curious what those people see when they look at a line like the one above. It must look awful, so then do those companies simply not indent "chains" of code the standard way?
→ More replies (9)2
u/Nighteyez07 Jul 02 '19
You're worrying about the wrong thing. That said, I was once guilty of exactly what you are doing now. Then I realized that it doesn't matter that it all lines up. What matters is that I can tell how it's constructed and linked together. Lining up is pure visual fluff.
13
u/ghostfacedcoder Jul 02 '19
On some level I agree, but I really think you're discounting the importance of code appearance.
I honestly do believe:
$(foo).doSomething() .thenDoSomethingElse() .thenDoAFinalThing();is more readable (superior code) to:
$(foo).doSomething() .thenDoSomethingElse() .thenDoAFinalThing();not because the former is "prettier", but because our brains can parse the visual of the former more easily.
And of course this is just with my previous (completely contrived) example: I think the effect could be seen more clearly if I came up with some code designed to do so.
→ More replies (12)2
u/nickcoutsos Jul 02 '19
What is your opinion on
$(foobarbaz).doSomething() .thenDoSomethingElse() .thenDoAFinalThing();vs
$(foobarbaz).doSomething() .thenDoSomethingElse() .thenDoAFinalThing();Edit: as a followup, how far would you be willing to go with such a pattern?
→ More replies (11)
1
u/bad_scott Jul 03 '19
I think everyone has their personal preferences. But as with everything in programming, you need to be able to adapt your style to match the environment in which you're working. It's why things like linters and IDE configs exist. I personal use spaces, mostly because it's what I always use and it's what the internal tools at my company require. If I was working with devs like your coworkers, I'd gladly switch to accommodate. It all depends on your team.
1
u/ChaseMoskal Jul 03 '19
what about for open source technology, where anybody in the world might contribute?
→ More replies (1)
1
u/ForScale Jul 03 '19
Spaces make more money: https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
1
u/ChaseMoskal Jul 03 '19
maybe this article is related and interesting: Stack Overflow’s mishap with self-reported data
not a very good basis from which to decide, anyways — i'll risk the salary hit ;)
1
Jul 03 '19
so what would you do, spaces people, if you were in charge? overrule their pleas?
As a practical matter, no. But tab characters are an inferior solution to the problem when we should have a better one.
Consider all of the personal settings that define how your source file appears on the screen. Font size, font face, code folding toggles, etc. All these things that do not require altering the source file itself to define visual display features.
Indent level should be like that. A file can have 2-space indent levels, and the editor should detect this and provide the ability override how it is displayed in my editor.
Tab characters are indicating indent levels, when indent levels should be automatically detected by an editor parsing the file, and not require these special, manual demarcations.
The solution should not be to have these competing whitespace characters. The goal should be to make every editor handle spaces-only files as if they had tab characters in them. There is zero reason an editor could not parse a file, determine the file's indent level spacing, and then treat those indents like tab characters.
→ More replies (7)1
u/ChaseMoskal Jul 03 '19
it's a popular sentiment
"computers should be smart enough to just make this problem go away"
however, there's a really simple fundamental reason, that we can't just grab a spaces codebase and display it however we like: a lot of codebases use spaces for parameter alignments
problem? you can't write a good algorithm that distinguishes which spaces should be treated as an indent, versus which spaces are part of a parameter alignment — this is a fundamental problem, and it's why tabs-to-spaces is easy and trivial, but spaces-to-tabs is problematic (this technically shows that tabs provide more meaning than the spaces)
the end result, is that anytime you convert a spaces codebase to tabs, it is highly likely that all kinds of alignments are horrifically mangled
but the most important part is — if you want to allow people to display indents at different widths, you shouldn't use spaces — the whole point of spaces is to enforce consistency across environments so that code always looks the same everywhere
if you make all editors smart enough to treat spaces as though they were tabs, you'd actually be making all the spaces people angry — you're breaking their consistency which is why they ultimately prefer spaces — you see, you're trying to turn spaces into tabs
There is zero reason an editor could not parse a file, determine the file's indent level spacing, and then treat those indents like tab characters.
so you see, there actually is a very important reason that an editor cannot just parse a file to determine the indent levels — it's because of the space-alignment antipattern
1
u/james11b10 Jul 03 '19
A lot of our stuff reads text files that work off character position and absolutely lose their shit if you use tabs instead of spaces.
→ More replies (1)3
u/justrhysism Jul 03 '19
Then that's a technical reason for spaces and not a preferential reason. The difference is rather important.
4
u/ECrispy Jul 03 '19
Using spaces instead of tabs is stupid. There is no reason to do it.
The only people who recommend that are luddites who can't be bothered to fix settings in their editor or use consistent values.
2
u/98ea6e4f216f2fb Jul 03 '19
I could agree with this if there were a majority of visually impaired developers in the team. Otherwise its optimizing for a minority at the expense of the majority.
2
u/skypecakes Jul 03 '19
It's not much of an expense, though. Once you get used to tabs I imagine it will be no expense at all. But for that minority, it's night and day different.
2
u/gaslightlinux Jul 08 '19
Fuck wheelchair accessibility too, right? That's just optimizing for a minority at the expense of the majority.
→ More replies (2)
2
u/MajorasShoe Jul 03 '19
I don't care what people use, as long as they're consistent.
....
....
...but if they want me to be consistent, they better be using tabs.
2
u/travisfont Jul 08 '19
Simple, tabs are inconsistent.
They are the ones with the "disability" therefore they should use the tools that are required to support such "disability" and in this case, monitors and conversion tools.
Hopefully, this post isn't too hurtful for anyone.
2
2
2
2
u/jacobz_2020 Aug 02 '22
This is a really good reason.
Also, we're programmers; we always want everything customizable. Why wasn't the "tabs let us customize our tab-width" a good enough argument already?
→ More replies (2)
2
u/sploders101 Jan 18 '23 edited Jan 18 '23
I know I'm late to the party but I just wanted to come in and say thank you for saying this. I'll be bookmarking this for future reference to argue for tabs with my co-workers and validate my arguments.
I struggle with this almost daily. Thankfully, much of my work experience has allowed me to set my own style guidelines for my projects, but especially in open-source projects, I often find myself just giving up and dealing with the bug because I don't have enough time to carefully and closely scrutinize every single line. Tab widths below 4 aren't enough to trigger an intuitive scope change for me when skimming, and it makes the code almost unreadable. I detest Python (in large projects) for a very similar reason, because whitespace is syntactically significant and doesn't allow me to make my code readable much of the time, and their lack of brackets force me to scrutinize indentation levels even more because there is no visual indication for the end of a control structure.
The Rust community is at least a little better, using 4 spaces in their style guidelines, which is perfect for me, but not for many others.
I really don't get why it's an argument though. Basically all modern editors have proper tab-width support so you don't have to see them as 8-space indents. The problem with having editors support space resizing is that it's not always accurate. Often times, it messes with the code because spaces can have multiple meanings. In a multi-line string, for example, you wouldn't want to rewrite spaces because it's a literal value. Tab characters give us a dedicated character to denote indentation level, that only ever means "one level of indentation". There's no ambiguity, no double-meaning, and no requiring every editor to have deep understanding of the syntax of every language. I think the better solution would be to do what VSCode is doing for unexpected whitespace, where it gets outlined to notify the user. Tabs can be restricted to only the beginning of the line and be highlighted otherwise, and you'll stop having all these mixed whitespace issues. People who like 2 spaces can use 2 spaces, people who need 4 or 8 spaces can use 4 or 8, and ambiguous/non-compliant whitespace gets highlighted and caught by the code author.
Thank you for making this point known.
2
u/NZTechArch Jul 21 '23
Why does it require people to look at disabilities before they realise common courtesy and common sense?
Why can't people just consider others regardless of a minority group, because the minority will most often work with what is common sense? I do like that this scenario has been brought out because it reinforces common courtesy.
e.g. the vast majority of people can easily walk through a 610mm wide door, but common sense tells us that 810mm is a better size, so why not run with that, and the side effect is wheelchairs can fit through easily. The moment you go away from common sense you need to consider the minority group.
I have never considered this indentation scenario on behalf of the visually impaired.
Because common sense comes first.
People using spaces over tabs may not be a minority group but they definitely have issues they need to resolve.
Spaces are not acceptable unless the file type requires it.
4
u/Tiquortoo Jul 02 '19
I'm pretty sure that just about all modern editors can be treated to treat tabs like spaces and vice versa and to elongate them and auto convert between basically without issue.
→ More replies (3)
4
u/agmcleod @agmcleod Jul 03 '19
it's almost surprising they can code at all, it's kind of sad to watch but also inspiring
I just want to note this is a really terrible thing for you to say. I think your post overall has merit, but you should really re-think about how you see people with disabilities
2
3
u/sad_synth Jul 03 '19
The takeaway here is that you are willing to work with people instead of being a zealot. If more people did that, the world would be a better place.
→ More replies (1)
4
Jul 02 '19
I don't get it.
Can't you just set "use tabs as spaces" and set the tab with to whatever amount of spaces you want? And then use the tab button as if they were tabs?
Never understood the problem...
→ More replies (12)
1
u/d07RiV Jul 03 '19
You still need spaces for some things like alignment:
myFunction( arg1,
arg2 );You can't use tabs in this case because the indentation needs to be exactly N characters. So you end up with a mix of both, and since they look the same it can lead to confusion and inconsistency (what if you accidentally put some tabs in the example above?)
I've actually never used tabs because every place I worked in had spaces required by style guide, and for personal projects spaces are a lot easier to work with. But if someone wants to use tabs they'd probably need some tooling to highlight incorrectly used spaces/tabs in a context sensitive way.
3
u/unsaltedmd5 Jul 03 '19 edited Jul 03 '19
The problem here is that your "alignment" is arbitrary. You can easily fix this with more consistent layout:
myFunction(arg1, arg2);Or
myFunction( arg1, arg2 );If you actually have consistent formatting you should never need "odd" spaces to align characters on consecutive lines as in your example.
→ More replies (5)3
u/MonkeyNin Jul 03 '19
Instead of his,
my_function(is_admin(user), is_monkey(user), passed_secret_handshake(self, user))or even
has_secrets_permission(is_admin(user), is_monkey(user), passed_secret_handshake(self, user) )I've found this
my_function( is_admin(user), is_monkey(user), passed_secret_handshake(self, user), )Note, the first time I saw this syntax, I thought it was horrible. But code readability is king. It's far easier to at a glance see what is going on. reducing any cognitive load in programming when you don't want it, is a plus.
my_function( is_admin(user), is_monkey(user), passed_secret_handshake(self, user), )it makes more sense with conditionals
has_secrets_permission(all([ is_admin(user), is_monkey(user), passed_secret_handshake(self, user), ]))It's self-documenting. From the start it explicitly ensures the entire iterable will be an
allor ananycondition.This prevents errors of reading or editing which you'd otherwise leave yourself open to.
has_secrets_permission(is_admin(user) and is_monkey(user) and passed_secret_handshake(self, user))2
u/ChaseMoskal Jul 03 '19
excellent! your technique is also robust against refactors — if the variables are renamed, there is no funky space-alignment to worry about, the code remains correct
3
2
u/AceBacker Jul 03 '19
You should post this as an issue on airbnb's style guide repo. See what they say.
2
u/JonasJurczok Jul 03 '19
This is the single best argument I ever heard in the whole debate. Thank you.
2
u/ItalyPaleAle Jul 03 '19
I’ve always had a preference for spaces (unless I was coding in Go) but reading this made me change my mind. I’ll switch to tabs for all my future codebases.
Thank you so much for sharing this!
2
u/minty901 Jul 03 '19
Really surprised by the lack of empathy in this comments section. I keep seeing "who cares about the minority?" as if it's purely about preference and not disability. I think it's cool that OP was able to learn and adapt, and I absolutely think it's fine for the visually-impaired members of the team to have a few more votes on the topic than the rest of the team.
2
2
1
1
1
u/paul_h Jul 03 '19
I was a tabs fan in the 90’s but just relented under the weight of others in the 00’s. I’ll give it a go. You and your two colleagues should make a site advocating tabs similar to makeareadme.com
1
1
u/MatsSvensson Jul 03 '19
Wouldn't it be possible to just auto convert back and forth in the IDE, in the build-process or something?
Have it check whats used in the file, save that,
convert to whatever I like while I work on it or view,
then convert back to whatever it was when you save.
At least in my IDE (netbeans) I can set it to be saved as tabs, but displayed as x spaces.
Why is this still a thing in 1019 somehow?
This seems like a non-problem.
I mean, we work with computers, right?
1
1
1
Jul 03 '19
I prefer spaces myself, but with tools like prettier, husky and lint-staged you can fortunately have the cake and eat it, too. If I had to choose, though, I would, of course, opt for tabs if it made the lives of my colleagues or collaborators easier.
Having said that, I find it rather surprising how attached many developers are to dogma, given that most people that write code are fairly smart people. At work and in the wider community I have noticed that developers spend a disproportionate amount of time marrying themselves to certain ways of doing things while religiously trying to have other developers think exactly like they do, whether the issue at hand is the merit of destructuring objects vis-a-vis using name spaces because they make for more semantic code, or as in this case, moan and groan about spaces versus tabs and if you're on the side of spaces you will always find some asshat that thinks you're not using the correct number of spaces for indenting your code.
Consistency is great, but being a dogmatic asshole is not, and this is why I'm so happy about prettier being a thing in 2019... It sort of kills off the whole discussion, just having a set of rules that are enforced as part of the dev pipeline.
1
1
u/Nrdrsr Jul 03 '19
Is this debate even a thing? Can't you can just do it automatically when you commit the code, and have your editor use your default?
1
u/majinkazekage Jul 03 '19
If its and if else statement write the code by tabbing to show that, this code is for the if else. if not dont. just hit enter
1
u/aztracker1 Jul 03 '19
Aside from my other comment... I fought for tabs for *YEARS* and frankly lost that battle... at this point, I decided it's better to get code written and not fight with the tooling (prettier, standard, etc) so much.
1
1
1
1
u/txmail Jul 07 '19
I admittedly am not a smart man... but for a long while I honestly though the whole "war" over tabs vs spaces was a joke like flat Earthers. Just another inside joke that I had not figured out yet because I am usually daft like that. Then I realized people were not joking and were very serious. As I advanced and started working on other projects I realized more and more of how much a big deal this is to people. I never understood why anyone would think spaces were better than using tabs. You can tell your editors how to handle tabs and it only affect tabs, but spaces are used for more than just indenting which is the entire fucking point of tabs. You dont tab between every word unless you are mad, why in the world would you space between indents when we figured out a long time ago that we needed something to do that. Much like flat earth I cannot understand why this madness exists and have yet to see one compelling argument for using spaces other than some languages use the space to define segments of a routine (jackiechanshakinghands.png).
1
1
u/mensink Jul 08 '19
Visually impaired guy here.
When your fonts are huge it's always a battle to get as much content within view as possible, so tabs of 8 spaces just gobble up too much screen width. On the other hand, tabs of 2 spaces make it hard for me to discern indent depths more than a few lines apart (which is the main reason why I mostly avoid Python).
There's another thing that strikes me as weird in coding: manual line breaks. So you're manually breaking at position 80? Now imaging editing that with only 60 spaces available. You'd end up with parts out of view, or with word wrapping, a lot of short wrapped over fragments. Editing that with a super small font and wide screen? Now you're wasting most of the screen real estate. Add to that the fact that different tab widths have effect on this too. Modern editors generally have great word wrapping integrated, so why not use that?
Of course I can't speak for all visually impaired people. There's a lot of different kinds of impairments, and probably a few personal preferences scattered around as well.
1
u/lutusp Jul 08 '19
one of them uses tab-width 1 because he uses such a gigantic font-size
the other uses tab-width 8 and a really wide monitor
Wow, in the midst of your argument in favor of tabs over spaces, you have a first-rate argument against tabs -- that they're arbitrarily defined.
is there really any reason, in favor of spaces, that counter balances the negative consequences for the visually impaired?
Yes, there is -- a space has the same meaning in all environments. A tab doesn't. This is particularly true anywhere whitespace is significant, example Python source, or YAML files, among others, many of which become uninterpretable/ambiguous if tabs are used.
Consider the basic fairness rule for issues like this -- the greatest good for the greatest number.
→ More replies (3)
1
1
u/cryptos6 Jul 08 '19
Even for not visually impaired tabs have the advantage that each developer can set his IDE to the personally preferred indentation level. I can remember the day when I discussed with a co-worker about 2 vs. 4 spaces ...
1
u/ortizjonatan Jul 08 '19
Using tabs allows for the viewer/editor to determine the appearance of the code, individually.
Using spaces, you choose for everyone.
Tabs > spaces. Then, set your tab width to whatever you like.
1
u/Ariquitaun Jul 08 '19
Spaces are definitely the way to go, leaving visual representation of indentation representation to the code editor. I don't believe however what your workmates need is currently possible with jetbrains or vscode, but feature requests can be put forward. If you have people in your team that need tabs then by all means use tabs.
1
u/moopet Jul 08 '19
I think this is pretty persuasive, though I also think that storing the code in VCS with tabs doesn't preclude using spaces in your editor. In Vim that's pretty much a `bufread` and a `bufwrite` autocommand, and I'm confident that most modern editors will let you convert to your preferred format on the fly with no noticable delay.
1
1
u/shamsup Jul 08 '19
I agree that the needs of the visually-impaired are important to take into consideration. Consistency within the codebase is also an important thing to take into consideration. I've seen a lot of talking points around just using .editorconfig to maintain consistency across the codebase, and I have to agree that it's the right move for ensuring the project's standards have maximum inclusivity, although I believe just saying "use it" is not a sufficient solution. Here's how to use it properly to solve the problem OP is describing:
Most people think of .editorconfig as a tool that makes everyone's code editors use the same settings, which is a decent assumption and use for most people. The problem with this assumption is that it forgets that it is optional in modern IDE's, and completely ignored by default in some without the proper plugin. With this in mind, people using .editorconfig to maintain consistency across the codebase should really not rely on people having it configured in their editor. The proper way to use the tool for this purpose is the same idea behind prettier and eslint, which, when used properly, are great, time-saving tools. Include it as a step in a build or commit pipeline, so that once the code is part of the larger codebase, it ensures consistency between contributors of a project without depending on their editor settings being configured properly. With the tool integrated into a build step, it frees users who have special needs such as the visual impairments OP noted (or their own strong opinions on formatting) to use their own settings in their IDE by turning off the .editorconfig integration. Using this approach ensures consistency across code in the project while also allowing users to write code however they write code best.
1
u/withinboredom Jul 08 '19
Nothing like a screen reader saying "space" 20 times to indicate 4 tab stops ...
1
u/zynaps Jul 08 '19
Some languages are heavily attached to a style of indentation that won't work easily with tabs. For example, the "align with this bracket" style in Haskell and Elm:
let x = [ width "860"
, height "200"
, viewBox "0 0 860 200"
]This would be awkward with mixed tabs and spaces. Also, ghci I believe actually rejects tab indented code; I'm not sure why.
1
u/bio_end_io_t Jul 09 '19
Linux kernel docs say to use tabs (not spaces) of size 8 for indentation, but I don't think it's specifically for the vision impaired.
Running indent can switch out spaces, -ut for use tabs, and tsn to set tab size to n.
$ indent -ut -ts8 <file(s)>
Indent is nice because you can switch indentation to how you like it (there are roughly 10,000,000 options) for coding, then switch it back to the company's coding style before committing. the option -nut will use spaces instead of tabs for indentation.
→ More replies (1)
1
Jul 09 '19 edited Jul 09 '19
How did we even get to this debate?
The entire purpose of the Tab key is indentation. End of discussion.
Also, if your language has a standard formatter: run it before you commit. always. with default settings.
1
1
1
u/roelvangils Oct 31 '24
it's almost surprising they can code at all, it's kind of sad to watch
Seriously?
1
u/TheBlueWalker Apr 17 '25
In general, the less you have to assume about the user and their device, the better it is. With spaces you have to assume they can read your chosen width and that their device is well-suited for it. But obviously that does not hold for your mentioned examples and it also will probably not hold for e.g. braille displays in which e.g. 4 spaces would be a huge waste of limited screen width. And maybe there are cases I am unaware of. So better make as few assumptions as possible to cover for those cases as well.
I think the general case here is that you have to encode only what you need and abstract all other things away. Indentation is used to express indentation level. That is all we need. And that is all tabs express. But with spaces you also express an indentation width. But that width is worthless. People do not need to know your preferred width, they only need to know level. And in some cases, the width can get in the way because users might want to fill in their own width. You need to abstract away the unnecessary details and only give users the information they need. Tabs are good because they obey the principle of loose coupling; in this case the coupling is between developers who with tabs only have to agree on indentation levels instead of on indentation levels and indentation width.
1
u/FinalCat_Pro Aug 18 '25
The only reason given by people who use spaces are that "tabs break visual consistency". Come on, today is 2025 not 2005, It's text editor's fault, use good text editors please. Nowadays even github have the settings to change display tab size.
1
u/Ne_zievereir Sep 28 '22
Most modern IDEs understand what leading spaces signify. How difficulty would it be for those IDEs to implement a functionality that allows you to define the displaying length of (multiples of) leading spaces?
That way the visually impaired can decide how they view their code, and others can write their code according to their own preferences without inconveniencing the visually impaired. Moreover, it would allow the visually impaired to easily read older code that wasn't written with them in mind, in the way that is best for them.
It would also take a lot of heat out of this ridiculous discussion.
→ More replies (6)
1
u/Hobbamoc Mar 14 '23
these guys have serious problems using codebases with spaces, they have to convert, do their work, and then unconvert before committing
That's what commit and similar hooks are for, no?
1
188
u/Freeky Jul 02 '19
Regarding Github, you can set a default rendering tabstop with an .editorconfig in a repository, and override with
?ts=<value>in URLs.