Yeah... I'm going there. I know I shouldn't. I know this is one of the most irrational and arbitrary subjects in all of software development. Bu...
For further actions, you may consider blocking this person and/or reporting abuse
Let's put an end to this never-ending debate and choose what 80 to 90% of devs nowadays choose: SPACES ! Let's stop this, it's a waste of time and it's not worth it.
(next debate: terminate your statements with a semicolon in Javascript, or not?)
P.S. if you still need an argument pro spaces (against tabs) - I feel that the right way is: source code should ONLY contain printable ASCII characters (with the sole exception of line feeds)
What if 80% of devs would jump from a bridge?
Also:
Doesn't make sense to me at all, except for the 80%, which I agree is not a strong argument.
I said there's ONE exception (newlines), so that's the one and only exception, simple.
The fundamental difference between a space and a tab is that with a space always occupies the width of one "space" - so I can right away see that they're spaces, and how many there are - assuming that we don't use tabs. But if you allows tabs then that breaks down, it violates the "WYSIWYG" principle.
Well I guess you can still argue about it, but if I'm leading the project then tabs won't enter my codebase :-)
Yes, that's my point: one is an arbitrary number.
But either way, what's the point of that rule in the first place? In what case will you run into problems because your source code contains "non printable" tab characters?
To me it seems like this is just a personal preference, which makes as much sense as writing code that rhymes. If you want to do it, sure, but why should the whole world adopt this minor aesthetic preference?
As for the WYSIWYG principle, that just doesn't make any sense. First of all, most modern editors can visualize tabs and spaces, so the practical difference is just not there. The only difference is that, if I decide to use an indentatino of 8, you will also be stuck with it when editing the same code (or, more realistically, I might be stuck with a tab width of 2 which I find uncomfortably small so I will be less likely to work in that codebase). Or should I be expected to re-indent every file before and after working on it?
Bingo! I don't personally mind someone arguing for spaces (or vice versa). But I'll admit that I do get annoyed whenever someone tries to argue for their preference by trying to twist it into some kinda empirical argument. I mean, if you really really like cinnamon, then throw it into all your dishes. You can even try to convince me to use it in all my dishes as well. But don't try to disguise your preference under some kinda faux-logical argument.
The key here is that those arguing for 2-space indentation don't really have empirical reasons for it. The simple fact is that they like 2-space indentation. Which is fine. I don't have any problem with that. Just acknowledge it for what it is.
Every argument that you can make in favor of 2-space indentation could also be made for 8-space indentation. But most "space fanboys" would think an 8-space standard is ridiculous. In fact, the more I think about it, the more I'm convinced that the only way to logically discuss space-based indentation is to say, "Cool. Let's set EIGHT spaces as the standard." And then observe the appalled and disgusted looks on the faces of those who were arguing for 2-space indentation.
Of course, if you were using tabs, there is no argument to be had. Because every individual dev can set their own default for tab width. So if I started arguing for 8-space tabs, the logical reply would be, "Sure, set them however you like in your IDE."
But when you use spaces instead of tabs, you're deciding, for everyone else, exactly how they need to view the code. And those who argue for 2-space indents don't care - because they like 2-space indents. But if you turned it around on them and said, "No. I think we should use EIGHT-space indents." They'd think that's patently absurd.
Well now you're talking, that's the only argument until now that makes sense - by choosing tabs for indentation you can choose how it looks visually i.e. how wide the indentation is, with spaces that's fixed and you don't have that flexibility. So yes, if you use tabs consistently and only for indentation then there's something to be said for it.
I have signed you up for a confidential membership in Tab-Lovers Anonymous.
Don't worry. I won't tell your friends. 😁
Thanks, well I hope they don't read this then!
"source code should ONLY contain printable ASCII characters" — try telling that (in 2020, where every mainstream high-level language already supports Unicode) to any developer who works and comments in a non-Latin-alphabet language.
Lol well yeah okay then, with the exception then of literal strings (texts) ... but you could argue that those texts should be in a separate bundle, rather than in the source code itself ... and let's not start using non-ASCII characters in variable/function names please ... I say programmers know English and stick to it (within their source code, at least)
Well I think we can all agree that you shouldn't use tabs (nor spaces) inside variable names! 😂
Exactly, and not anywhere else either ;-)
This is why things like prettier.io exist along with ESLint. As an instructor, many new programming students have some sloppy habits. I provide all of the settings/configurations and automate the process of linting/prettifying the code so they don't have to be involved with '🚵🏽♂️ shedding' situations like this. They just code things up pretty much, however, stylistically speaking, and it's 'auto-magically' cleaned. Eventually, they get '🧠washed' into following some best practices.
Here's one example for Node
There's no brainwashing quite like subtle brainwashing. 😉
CLEANSE!
My source code contains emojis
What, in your variables names? 😉 okay I give up, let anyone just use whatever they like, even if they want to use aliens out of space (but not out of tab)
emojicode.org/
Terminte, because then at the end of every statement you can say; “you’ve been terminated”.
I’ll see myself out.
He's here all week, folks. Tip your waiters.
What if the 10 to 20% were right all along?
Yeah forget about the 80 or 90%, that was the weakest argument ;-)
Democracy is two wolves and a sheep voting on tonight's menu...
Yeah. And because of that "Fork" button, or its equivalent, on most open source code bases, just like the Second Amendment, coders also have the equivalent to some correction mechanisms on Democracy's excesses, Federalism and the Bill of Rights.
If you go too far, the sheep juuuuuust might fork ya.
If I may extend the metaphor beyond the point of usefulness, there's a valid concern in the backs of the minds of the wolves about armed sheep.
Super great look at your experience!
I want to like tabs. They're the semantically correct character to use. But it's like you said: with spaces, I know (for sure) that the way I see my code is the same way you or anyone else will see it because there's only one way to render a space; with tabs, i don't know if you will have a good experience or not, because it depends on all your tools being set up to handle tabs sensibly (IDE, command line, git, github, etc.)
And worst case (pre-lintinters) someone invariably mixes spaces in with tabs (in my experience) . It looks fine to them because they have the same number of spaces as their tab-width, but to anyone else it's downright horrible.
And a side note on non-code tab usage. I should be able to tab separate values and whatever renders that should figure out how wide the space needs to be to vertically align items with the same number of tabs deep (regardless of length of data in between previous tabs). A tab le if you will. But has that ever worked? Tab being a rarer character makes much more sense to use than commas, commas are everywhere, and yet...
Here's another way to think about the "good experience" that others may-or-may-not have when reading your code:
Every dev that I've seen coding over the last couple of decades uses some form of code coloring. Sometimes it's subtle (like the default coloring in Eclipse, with a white background and a lot of black text - and only certain things colored). Sometimes it's more glaring (like Sublime's default "Twilight" theme). But the points I'm trying to hit here are that:
Thankfully, none of these points are much of a "concern" to anyone. That's because we can all set our own IDE to use the color scheme that's best for us. If someone complains that the color scheme in their IDE makes it hard to read the code, and they aren't having a "good experience", the logical answer is, "Well, then spend a little time to change your color scheme and find one that works for you."
But imagine if you couldn't set your own color scheme. Imagine if the team had decided for you that you would use a particular color scheme - regardless of what you think about it. And imagine that the color choice was somehow codified directly in the project itself. So every time you open one of those code files, you have no choice but to read the code file in a color scheme that's been dictated by the programmer/team/style guide. Would you appreciate that level of forced conformity??
That's what spaces do. They decide for you how you will read the code - even though we could use tabs, and everyone could decide for themselves how they prefer to read it.
A good analogy I think! In some ways it breaks down I think; color-coding is derived from the parsed meaning of the code where indention (aside from python and edge-cases) has no meaning to the interpretation of the code. Indention is only there for those reading it and has no effect on program execution... hmmm so actually, should we just stop indenting our code at all and have our IDE's decide how much indention to render (they already basically do this with helpful pre-indenting lines in many cases)?
(that would also solve the "whitespace-only" diff problems in git 🤔)
Our IDEs absolutely do decide "how much indentation to render". But that's not really the question. The question is: How wide is each indentation??
People can laugh at my geriatric-ness if they like, but the simple fact is that there are many times when my eye tends to get "lost" when I try to follow multiple, indented layers of logic that are only represented by 2 spaces. For my personal taste, if I can simply add one more space to the width, all of that confusion goes away. And if we used tabs, we could all determine an indentation width that works for each of us.
But with spaces, that ability is taken away from me. I must view it with 2-space widths - because someone else decided that's the way that I "should" read the code - even if that way is harder for me to follow.
Please don't apply that argument to syntax.
There's already enough people complaining that Anglicization of programming languages is some kind of Marxist oppression.
Exactly: Now consider that, no matter how much you like yow you see your code, someone else might feel differently about it. Accessibility is one factor, screen space is another, and someone might just like an indentation of 7 because it's prime.
The thing is: you don't need to worry. One tab means one level of indentation. It doesn't have to look the same for everyone, and I can't think of a scenario where some code might look worse because of a different tab width.
I agree; I'm very much focused on my "worst case" scenario of mixed tabs and spaces.
Semantically I'm on team tabs; but practically I see why spaces have been chosen.
I hear that "worst case" example of mixed tabs and spaces a lot, but it doesn't really make sense to me:
If using tabs would cause trouble because people would push code with spaces, how come it's not a problem when using spaces that people would push code with tabs?
Also, this can easily be tested, so people would see that the tests fail and correct it.
I felt like trying it out and just added a test to one of my projects that checks whether all the code files are indented with spaces:
github.com/DarkWiiPlayer/restia/bl...
It was easier than expected :D
With all due respect, I think that your "worst case" scenario is a bit of a contrived edge case. I'm not claiming that there aren't certain styles that use tabs and spaces. But I am claiming that, if you've purposely chosen a style that mixes both, you are pretty far out of the mainstream and probably implementing that "mixed" standard to make some kinda point.
@defman illustrated how that example could easily be handled by using only tabs. And of course, it could easily be handled by using only spaces. If you personally insist on using both, well, that's fine. But I can't really use that as an explanation of why tabs are bad and spaces are good.
But there's no need (other than personal preferences) to use both tabs and spaces. After writing Java code for years, there was never a single moment when I (or anyone around me) said, "Dang! This is just so difficult because I can only use tabs for my indentation, and not spaces." And of course, I've never heard anyone using spaces who complained that they couldn't achieve the proper formatting.
To be absolutely clear, I prefer tabs. But if the team insists on using spaces, then the clearly-superior approach is to... wait for it... use spaces. As a shared standard.
I'm gonna pick on you a bit, just because you spelled out this particular sentiment (that I loathe in programming). I don't mean it as anything personal. But here's your quote:
This is what really drives me bonkers sometimes about those who advocate spaces. They're not content to see things with, say, a 2-space indent in their IDE. They must ensure that everyone else is looking at the code with a 2-space indent. We now have these amazingly sophisticated IDEs that can do so much to format code however a particular dev wants to see it. But when you use spaces, you basically undercut all of that functionality.
It's quite possible that you prefer 2-space indents, and Mary prefers 1-space indents, and Joe prefers 9-space indents. And with tabs, everyone can view the code in the way that's most comfortable for them. But I've run into soooo many coders who feel it's imperative that I read code in the way that is most comfortable for them. IMHO, it's one of the most nonsensical forms of control that I've witnessed in dev. I'm sorry, but it's just sorta silly to imply that, if you see the code in your IDE with 2-space indentation, that there's anything wrong if I view that same code with 3-space indentation.
The key here is that you shouldn't be responsible for whether or not I "have a good experience or not". I'm a big boy. I can configure my IDE. If the tabs in the code are too wide or narrow for my taste, I can fix it. And it's not like you have to do a bunch of work to get an IDE to "handle tabs sensibly". It's 2020. As far as I've seen, every IDE handles tabs "sensibly" out-of-the-box. You may want to adjust them to your liking. But it's not as though opening a code file with tabs will blow up an IDE unless it's been heavily pre-configured.
But when you peg everything to a 2-space indent, you're basically saying, "Are those indents too narrow for you? Does it make it harder for you to read the code? Well, guess what?? I don't friggin care. Because I wrote the code with 2-space indents on my monitor. And therefore, everyone else should have to look at it in the exact same way!"
I totally agree with this. Although I would prefer tabs if it were my choice (usually, it's not), I do understand that you need to pick tabs-or-spaces. Because if you start mixing them up in the same project, files start to become a mess when others open them.
Thanks for picking on me! :P
I want to agree with you; and I don't want to "control" how you view the code. I'll clarify that I really am focused on the "worst case" of mixed tabs and spaces in my opinion on "know[ing] that the way I see my code is the same way you or anyone else will see it". Which some styles of coding would essentially require mixing tabs and spaces; see this multilined example of a validation in ruby on rails (borrowed from real examples I've seen in production code):
(We can have a separate discussion on if this is a good style or not, but) How would I write that with tabs? should I have 2 tabs and 2 spaces? 4 tabs and 2 spaces? 10 spaces? Now I have mixed indention that will be subtly broken for everyone who isn't me.
Just as a counterpoint; not all code is written and read in IDEs. They also appear in command lines; in git clients; in GitHub (or GitLab or BitBucket etc.); in CodePen's; in StackOverflow; in DEV posts and comments :) ...
To be honest, it shouldn't be that difficult for these "sophisticated" IDEs to solve this problem by treating groups of 2 or 4 (or whatever) spaces as something to be rendered with a different width (same width as
tabwould be). This solves the problem of always being forced to see unaccessible indentation with the problem of getting all the various places code appears to render tabs "correctly".So, semantically I want tabs; but for historical reasons I see why spaces were chosen.
If everyone used tabs, your code example would probably look something like this:
It seems logical to me (a statement with the arguments being a nested thing (thus the indentation)). This would not introduce the problem you described (mixing tabs and spaces), though it might not be liked by some people because there's one line that could be gone.
In my previous job I succeeded in enforcing 4-space indentation to JS codebases, although mostly because for a long time I was the only mainly JavaScript developer around. However now that I'm gone I kinda expect the new guys to eventually swap it over as they really seemed to go for anything that is trendy.
Then there is the fact that tools like Prettier default to 2-space, and have edge case rules that end up to 2-space indentation even when you tell it to indent by 4-space. That is just silly.
Would prefer tabs because then you could just set the indentation to whatever you prefer over being forced to 2-space soup. If JS devs knew CSS (most of them really don't even if they claim to) you'd just tell
tab-size: 4or whatever you like. Actually, it might be Internet Explorer that killed tabs, because IE never supportedtab-size. Chrome added support in version 21... in July 2012. Firefox added support in early 2011. So I guess you could argue tabs were killed by browser CSS by not having support fortab-sizeuntil around 2013 considering evergreen browsers was still an emerging idea at the time.When I've been lucky enough to do green-fields work, I've lobbied the rest of the team for 3-space indents. And the funny thing is that I've never gotten any pushback on it. No one else ever seems to mind. Which is doubly-frustrating for me, because 2-space indents actually present a (minor) difficulty for me. And yet I'm typically looking at 2-space-indented code simply because someone decided years ago that it should be the standard for JS.
You make a really good point about the
tab-sizeCSS feature. If you accept my contention that viewing code in browsers exacerbates the tab hatred, then it makes sense to point the finger at the lack of configurable tab sizes in HTML (in the past). I hadn't even thought of it to that level.On an even-more-tangential note, it still baffles me that the default indentation for tabs in HTML is 8 spaces. I'm not sure where that came from. I can't think of any other tool I've ever opened where 8-space indents were the default way to display a
TABcharacter.Fun fact, you can do this:
github.com/DarkWiiPlayer/restia/bl...
vs.
github.com/DarkWiiPlayer/restia/bl...
(Note the
?ts=3at the end)This works with pretty much all GitHub links, and recently also works with gist.github.com links. It's annoying that the default isn't something more reasonable (maybe 4?), but you can change it quite easily.
That's cool! I hadn't seen that little query string variable option before.
One guy claimed that Sun Java source was written in 8 tabs and was not very readable if you tried to look at it in 4 tabs.
But this is also interesting about Linux kernel docs: simplystatistics.org/2018/07/27/wh...
So can we blame Linus Torvalds? It would be nice to get some anger back from him.
But interesting in general that there actually were 8-space indents in the 90's.
I also wonder if the 8-space tabs could have come from spreadsheet editors of the old age. Weren't the cells 8 characters by default?
Ooh, I like that link. Specifically, I like the idea of using longer tab lengths to highlight potential code smells. Despite my long experience, it was only about, ohh, 4-5 years ago when I really started aggressively attacking my own nested code blocks. Originally, I didn't see much problem with them. But I've now come over to the camp that
deeperNesting === codeThatShouldProbablyBeRefactored.As for the spreadsheet observation - yeah... I think that may be one of the original culprits. I know I've heard that before.
I always blame POSIX in in-person conversation, because nobody will bother to look it up.
Tabs. Why? Because I use 3-space indentation. Do you want my 3-space indentation? No? With tabs you can just configure it to whatever you want. With spaces? Good luck, you're screwed.
I have yet to see a single good argument for spaces, and for tabs there are exactly two:
The dumbest argument for spaces I've heard is (Paraphrasing):
Which, in principle, applies the exact same way the other way around, so it's really just another way of saying "everyone else is doing it"
My theory for why spaces became popular:
They Look the same Everywhere™
You can write some code on one editor, then open it in some other editor and the indentation is exactly as you left it. I guess you could blame modern editors for not adopting something shorter than 8-space tabs as a default, but I think it's a realistic demand that users either configure their editor to how they like them or just deal with it if it's a super tiny edit.
This reminds me a lot of how many bad practices in the front-end world came to be: people want their creations to look the same everywhere, instead of setting guidelines and letting the browser handle the specifics. In that sense, spaces are the
pxof the source; tabs are theem.There has been a strong push for "Developer Experience" (which has some stuff that I think makes things actually worse...) so maybe we could start Developer A11Y push, too.
You can find space hacks everywhere now, for example Styled Components has bits of code that determines level of indentation by number of spaces on a certain line. I expect the logic to fail if tabs were used. It also relies on Prettier to exist.
Great points. And yeah... I think the they look the same Everywhere argument sways a lot of people. But that argument also ticks me off. Everything else about modern IDEs is designed to ensure that we can all look at the same code - but we can all view it in a way that is best for each of us. But with spaces, that ability is taken away. It's a nasty brand of arrogance that says, "You must look at this code in the exact same way that I look at it."
I won't repeat a ton of verbiage here, but if you read down a few comments, you'll see where I compared this to code coloring. For some reason, no one thinks it'd be cool to force every dev to read a given code file with the same coloring scheme. (And thank goodness that they don't.) But they think it's perfectly kosher to dictate that we must all read that code with the exact same indentation.
As a curmudgeonly 50-year-old software engineer, I do like spaces vs tabs. And, yes, I like it because it is consistent. Sometimes I use an IDE. Sometimes I use vi (which I occasionally call six, just to annoy).
But the thing I do find annoying that, more and more, I'm seeing development organizations using prettifiers and reformatters to enforce sameness across code. Thus it becomes annoying when you work on a piece of code just to have a bot either reformat it or wag its finger at you saying it's too complex.
I, for better or worse, feel that it is better for developers to be exposed to more diversity in coding (beyond the whole spaces/tabs thing) as, no matter where you go, you're going to see some differences anyway. Sometimes these differences can help you improve your own code by learning tips and tricks that reformatters are often configured to rewrite.
Ugh. End rant.
This sentence alone makes me like you.
I mostly agree with you. The only "modification" I'd add is that: I don't mind those tools. If they work for you (or your team), then, great! I only "mind" those tools when I feel that I almost have to use them to work around the other arbitrary rules that have been forced upon us by the standards / style guides.
Truly, this is a beautiful sentiment. I feel that it kinda falls in line with other things I've blogged about in the past. But I also think it might become its own blog topic in the not-too-distant future.
At some point, in the desperate search for code "quality", people decided that this could be accomplished with slavish conformity and sameness.
But "quality" is more than just ensuring that everyone's code looks like a carbon copy. And... to your point, there are some wonderful "a-ha!" moments to be had when you're perusing someone else's code that isn't "wrong" - but is just a little different from your own.
Step your troll game up a level of annoyance and call it eleven. You're welcome.
A haiku
For me it comes down to how the cursor behaves as I am moving around my code.
When indents are spaced, if I am in the empty indent area I know where I will be when I press the down or up arrow. The cursor moves in a straight line. I know where it is. I know where it will be.
When indents are tabbed, if I move into the empty indent area, my cursor will be relocated to the tab stop. My cursor does not move in a straight line. Additionally I can't guarantee when I move up or down the cursor will be at the tab stop position. This causes me to overshoot. This annoys me.
I also wish that the cursor didn't snap to the end of shorter lines. That annoys me too.
I never use the tab key for anything other than navigation. The web has broken the use of tab for indentation (like here if I'm typing in a box and want to tab, I'll move to the next available input field instead).
I let my editor do the indentation for me, and if I need to re-indent, I use a command for that too.
I kinda figured that someone would chime in to refute me on this. 😁 And that's totally cool.
But I assume you would agree with me that you are quite an outlier in that regard??
I might be, but I'm not sure - because of the web navigation issue I mentioned :)
Fantastic explanation, love your thought process.
As you mentioned, I might argue that converting all indentation to spaces with editor settings makes everyone happy in their own way since they can set indentation per project or language. So really that tab to spaces conversion allows us to work together in a consistent manner, and we have this interest in spaces to thank for it.
Although, as a self counterpoint, we wouldn't have to worry about that consistency if we'd just stuck with tabs on the first place...
Either way, I'm definitely one of those devs that uses the Tab key to input that indentation, and that will never change as long as the Tab key exists. To hell with using the space bar!
Well... It doesn't make me happy. Because when I open the files in our project, everything's set to 2-space indents. And it doesn't matter if I change the width of my tabs. The file will still have every layer nested - by 2 spaces.
Then again, I'm old. And continually rather cranky. So maybe it wouldn't make any difference even if the entire world gave in to my evil demands of All Tabs, All The Time.
But I appreciate your feedback! I'm glad you enjoyed the article.
Ah well yeah, the 2 spaces setting is annoying. I get that. If we could just get everyone to agree on 3 or 4 spaces... I'd say that's the real issue.
I completely feel you. I've been writing code around 5 years now. Not really such a long way, but long enough to watch people ask me "Why do you use tabs?"
I truly didn't know when I started about conventions or standards. Caming from a non engineering or related background, it just felt natural to press tab and watch it indent once, with a tab.
Even if its just a matter of preference, I think preferences and standards should be guided to working more efficently, tabs are just easier to read like you pointed out.
I try not to get too much into the empirical arguments - because they tend to become circular, based on your own preferences. But when I do allow myself to go down the rabbit hole of actually quantifying why anyone would use tabs or spaces, I can't help but point out that:
According to Merriam-Webster, a "tab" is
a key on a keyboard that indents text by a preset amount. In other words, the tab characters (which are created with theTABkey) do exactly what is called for when we say that you should indent your code.Everyone I know who hates tabs, still uses the
TABkey... to insert spaces (indentation) in their code.But such "logical" arguments get lost in a lot of passion and vitriol. Devs just don't seem to be able to talk rationally about it.
Very fair points.
I think it's not only a matter of passion, it comes down to changing habits and codebases.
The ball is already rolling for many javascript projects. At one point, people who might accept for a moment the idea of using tab, go back to work where all the files are indentend with two spaces, and the amount of work required to change that is not worth it.
You also seem to have a much shorter level of patience for the typical bs, without the acerbity with which I respond to it. Which is why I'm reading more of what you write, now.
I hadn't thought about accessibility before in this discussion. That is very interesting.
Anyway, here is a fix for anyone who likes tabs working with spaces people. I just tested it and it works:
stackoverflow.com/questions/231667...
You: Who killed the tab?
Me: Probably either Ruby or Python
You: Code needs to be "pretty" now...
Me: Python killed it, Python killed tab
You: Why TWO spaces???
Me: Ok nevermind it was Ruby
😂 😂 😂
I’m one of those horrible tabs and spaces people. What can I say, my fingers have a mind of their own.
I use tabs everywhere, I let prettier to fix that for me, I was shocked as you are when spaces became trendy. But I am a guy coming from c/java/c# to the frontend world.
I probably need to take a new look at prettier. A few years ago, I tried to use it to solve my 2-space indent "problem". But there was something about the way I had it configured that was actually causing more headaches than it was worth. I couldn't get it to consistently convert back-and-to-and-back again.
Spaces are VHS, and tabs are Betamax. Except in this analogy, Betamax is not only substantively better but also cheaper.
That's actually a great analogy. I'm always fascinated by the VHS/Betamax case study - partially because we actually HAD a Betamax machine in my house when I was a kid. But moreso because it's somewhat baffling to me whenever the "lesser" solution wins.
I guess that part of my frustration around tabs-vs-spaces is that spaces hasn't necessarily "won" so much as it's bullied its way into a certain space (primarily, JS development).
If spaces had replaced tabs in most of all programming, it'd actually be easier for me to just "deal with it". But it's frustrating to know that, if I'm going back to Java work, no one has any problem with tabs. But when I flip over to JS, I'll literally be code shamed if I try to check in something that uses tabs.
Excellent post, really.
Thank you!
I would say, just use a pre-commit hook and let it auto format the code to a uniform layout. I don’t care if it has spaces or tabs, just pick a uniform layout for the application.