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. But this has been pinging around my brain ever since I started blogging and it was only a matter of time before it burst out.
This is not a treatise for-or-against spaces - or tabs. This is not an attempt to change your mind on this most-divisive of subjects. (I know, from painful experience, that there is no changing of anyone's mind on this subject.) Instead, this is my honest attempt to figure out: How did we get here??
Some Anecdotal History
I don't pretend that my view of history will, in any way, match your view of the same history. But I can say, with empirical confidence, that I tend to have a longer view of history than most of my colleagues. Because, in this career field, staring down 50 often makes you 10-15 years older than most of your coworkers. So... here's my (ancient) perspective on this matter:
Although I wrote my first programs in the 80s (in GW-BASIC, on a Coleco Adam - with a tape drive), I didn't really become a "programmer", in any professional sense, until the latter half of the 90s. I had my first web-based business by 1997. I wasn't actually paid - by an outside employer - until 2001. But I was starting to write code, in excess of 40 hours per week, as early as 1997.
Back in those days, there were really only two types of developers (that I knew about). They were:
The pros. They typically only wrote in one of several languages: C, C++, or Java. (The real "old-timers" wrote in COBOL.) They spent endless hours arguing about memory management, and pointers, and garbage collection. And as far as I knew, every single one of them used tabs.
Everyone else. This included anyone who was writing on the nascent internet. There were no "JavaScript developers" at that time. But there were definitely some more "hardcore" guys who were doing Perl. Then PHP birthed a whole ecosystem of what the "pros" derisively called script kiddies. But as far as I knew, every single Perl/PHP developer used tabs.
Although I'd been working as a developer (for myself) for several years, I wasn't welcomed into the world of corporate IT until 2001. Through some odd confluence of factors, I ended up writing a lot of ColdFusion from 2001 through 2007. (I'm not particularly proud of it - but it paid the bills and allowed me to build a resume.) In the ColdFusion shop in which I worked (which included as many as 90 developers), we all used tabs.
At some magical point in time, JavaScript finally grew into its own "thing". And when it did, it apparently sprung forth from the mind of Brendan Eich, intent on one sole purpose: To eradicate the tab.
I don't think I started paying serious attention to JavaScript until, oh... 2012 or so. By then, it was already clear that there was "something" about my development that was sadly out-of-date. Even back in 2012, it was obvious that my preferred tabs were putting me in conflict with other dogmatic developers.
But I was confused - soooo confused. How had it happened that, seemingly overnight, the "standard" for indentation had flipped? And it had flipped in such a way that devs across the world were lining up with pitchforks and torches! It simply didn't make sense to me. In fact... it still doesn't.
The Language Conundrum
If the entire programming community had decided that "tabs are bad" and "spaces are good", I might've had an easier time accepting the paradigm shift. If you've been around dev long enough, you realize that sometimes these kinds of things happen. Standards evolve. "Best practices" emerge. Sometimes... that thing you were doing for years is now viewed as an anti-pattern. And for the most part, that's... OK. I get it.
But as far as I can tell, the "spaces-over-tabs revolution" is far from universal. In fact, it seems to be particularly ensconced in front-end languages. I could point my finger solely at JS, but I believe it's more generic than that.
It "feels" (to me) that most of the "space fanboys" are centered upon frontend technologies. (Many frontend technologies are centered upon JS - but not all of them.) And most of the "tab fanboys" are centered upon more old-skool, compiled, backend-kinda technologies.
Just a few years ago, I was working for a large health insurance clearinghouse. They had a lot of backend Java code - that I was responsible for working on. And they had a lot of frontend JS code - that I was also responsible for working on.
The frontend (JS) code was, without question, always written with space-based indentation. The backend (Java) code was, without question, always written with tab-based indentation. Maybe that doesn't sound "odd" to you. Maybe you're nodding your head thinking, "Yeah... so??" But for me, this struck me as being incredibly... arbitrary.
I mean, if tabs have truly been deemed as "bad", then why were they still acceptable in our Java code?? (With modern IDEs, you could convert the entire codebase in mere minutes.) And if the older, more stable, "industrial-grade" Java code was just fine with tabs, why was it considered so obvious that spaces were the default choice in our JS code??
The more I've gone down this rabbit hole, the more I'm flummoxed by the idea that, in one language, tabs are inherently evil. Yet, in another language, tabs aren't just acceptable - they're the standard.
Maybe this analogy doesn't fit. But in pretty much every OOP language I've used, there's been a movement over the last decade-or-so to favor composition over inheritance. That movement doesn't only apply to Java. Or C#. Or any other OOP language.
We don't use composition over inheritance in Java, and inheritance over composition in C#. If you believe in composition over inheritance, you try to use it... everywhere. It's a design imperative that programmers have come to accept - regardless of which OOP language you're using.
But when it comes to the the age-old, contentious question of tabs-vs-spaces, it seems to come down to language-based standards. Trends. As though a tab makes perfect sense in one language - but is unconscionable in another language.
But again, I come back to my central question: How did we get here??
The Petty Rules Lawyers
For awhile, I was frustrated by some of the downright silly arguments I read to justify spaces over tabs. Some of these half-baked ideas include:
Efficiency - You've probably seen some of those skits where one programmer starts hitting the
SPACEbar repeatedly to accomplish indentation. The other one is only hitting theTABkey. And eventually, they start arguing with each other to point of throwing furniture and slamming doors. But here's the thing: No one (that I've ever met) actually uses theSPACEbar to do indentation. Every single time I've watched another developer code, they always use theTABkey. They just configure their IDE to insert X number of spaces every time they hitTAB. So "space fanboys" and "tab fanboys" are using the exact-same number of keystrokes. (But "space fanboys" are convinced that tabs are evil - even though they always use theTABkey. Hmm...)Memory/Bandwidth - IDEs and source control systems have been able to strip trailing spaces for the better part of the last two decades. They are also capable of storing consecutive characters without having to allocate memory for every member in the sequence. So I can't, for the life of me, understand how anyone can argue, with a straight face in this modern day, that either approach presents a memory/bandwidth "issue".
Consistency - The "space fanboys" indent their code blocks - every single time - with a set number of spaces. Nested blocks are represented by
indentSpaces = nestedLayers x standardSpacesPerIndent. It's consistent. The "tab fanboys" indent their code blocks - every single time - with a single tab. Nested blocks are represented byindentTabs = nestedLayers. It's consistent.
I could go on, plowing through a pile of arbitrary arguments used to justify one-or-the-other. But the point is that none of these arguments really seem to indicate exactly why someone prefers one over the other. People throw up these flimsy points - but it's pretty clear that they're really arguing in favor of their own preference.
At this point, I've yet to hear anyone give me an empirical, logically-consistent argument in this debate. When I realized that all of the "logical" arguments on either side of this Holy War were, well... illogical, I started looking to broader influences to explain the switch.
Evil Corporations
For a time, I blamed the Evil Corporations for this divisive Holy War. Specifically, I pointed my bony finger of judgment at Airbnb and Google. Even more specifically, I ranted against their all-too-ubiquitous style guides. These style guides decreed (amongst many other things):
Thou shalt only use space-based indentation.
That indentation shall be two - and only two - spaces.
At this point, I should probably come clean about one critical point. If you'd ever like to get me fired by enticing me to take a swing at you, the most effective approach would probably be to tell me, "Well, the Airbnb style guide says that we should..." or "The Google style guide says that we should..."
It's not that I have a problem with style guides, per se. And if your particular style-guide-of-choice is the Airbnb style guide or the Google style guide, then... great! Run with that! Standards are almost always a good thing.
What I do have a problem with is when otherwise-intelligent programmers abandon rational thought and hand over the reins of their critical thinking to some nebulous "standard". I understand that you can't be bothered to think deeply about every minute detail in the Airbnb/Google style guides. But if your only rationale for doing things a certain way is: That's what's outlined in the style guide. Well, then... you should probably learn to tie your shoes on your own and exercise some of your own brain cells.
I'm sure I'm being somewhat dramatic here, but for a while in the mid-10s, I truly felt like nearly every aesthetic coding decision in JavaScript would be distilled down to "Well, the style guide says we should do it this way..." If someone had managed to hack the Airbnb Style Guide site, and insert a rule stating that every-other line of code must be a comment that reads: // fnord!!!, we would've started seeing those comments in production code within weeks.
Alas, despite my cranky-old-guy propensity to rage against the machine, I eventually realized that spaces-vs-tabs predated the Airbnb/Google style guides. It's tempting to blame them for codifying two-space indents. But it's misplaced to assume that they started this debate - or that they settled it. They just put down, in (digital) writing, what had already been percolating across many dev communities.
So if we can't blame the big bad corporate bullies for this Holy War, how do we explain the rise of this endless, amorphous debate?
Combatting Chaos
When I broadened my focus, beyond the easy boogeymen of Airbnb or Google, I started thinking about the nature of the web. And the way in which JavaScript came of age - and the way in which it proliferates.
Remember when I said that, in a previous job, all of our Java code used tabs? Well... nearly everyone in the company used Eclipse as their IDE. Do you want to take a guess as to what the default indentation is when you install Eclipse??
C# is almost always written with 4-space indentation. Quite different from the defaults we see in Eclipse. In fact, it's quite unique from many other languages that are out there. But why is this the go-to default for C#?? Well... the vast majority of C# code is written in Visual Studio. (We could give a slight nod here to the rising popularity of VS Code. But the simple fact is that "plain old" Visual Studio is still the hands-down choice in nearly all professional dev shops for writing C#.) Do you want to take a guess as to what the default indentation is when you install Visual Studio??
Now let's think about JavaScript. Despite the rise of several dominant platforms (like, VS Code), there has never been a "default" IDE for writing JS. And there still is no such thing. The devs in your shop may all use a given tool. But JS devs across the world still use a variety of starkly different IDEs to complete their work. And each of those IDEs come with their own unique defaults.
As I'll explain, I don't think the "chaotic" and distributed nature of web (JS) development entirely explains the trend to force two-space indentation on everyone. But I think it's a good starting point. From the earliest days of the language, there was no "default" IDE for JS development. Therefore, there was no default setting for indentation.
But there's more to this picture. Chaos may explain the lack of standards in early JS dev. But it can't explain the heavy-handed enforcement of new standards.
Collaboration Spawns Conformity
JavaScript was first released in 1995. In 1995, I don't remember anyone arguing about tabs-vs-spaces. I especially don't remember any such discussion regarding JavaScript.
That's easy enough to explain. For the first 10-or-so years of JS's existence, there really were no "professional" JS devs. During its first decade, calling yourself "a developer - who specializes in JS" was akin to calling yourself "an architect - who specializes in building virtual homes in Second Life." JS was a toy. It was rarely used in "real" dev projects and, when it was, it was typically written by some lonely soul unattached from a broader dev team.
Those limitations started to melt away in 2006. That's when jQuery was released. Granted, devs weren't falling all over themselves to embrace JS in 2006. But jQuery's release marked the beginning of a swift evolution - one where "JS Developer" graduated from being an under-your-breath joke, to a full-fledged career path.
What does any of this have to do with tabs-vs-spaces?? Well... I'm glad you asked.
When you're writing code by yourself, with the dev tools that you've personally chosen, no one much cares how you indent your code. Heck... when you're only writing code by yourself, it doesn't even matter much whether you indent your code at all. When you're a maverick, you can do whatever the hell you want.
But once jQuery started gaining serious traction (I'll arbitrarily peg that date as: 2008), we started to see something entirely new in the JS community. We started to see professional teams of JS devs, working and collaborating together. While this was nothing novel for, say, a Java developer. It was an entirely new development for all those JS script kiddies.
You could put 100 mad geniuses in 100 separate caves to write 100 separate codebases. And since they're all geniuses, you could assume that all of their code is brilliant. Revolutionary, even. But that doesn't mean it would be consistent, or even compatible.
Even for those "mad geniuses", if you forced them to start sharing their code so they could collaborate on it, you'd be sure to run into some... issues. It'd be like asking 100 musical ingenues to write 100 songs. They might all be amazing - but they wouldn't sound good together.
So I imagine that there were a ton of headaches amongst the nascent JS community when companies started forming "real" dev teams. All the C# guys were already using 4-space indents. All the Java guys were already using tabs. But all the JS guys? Well... they were using... a whole bunch of different approaches. And when all those "approaches" get checked in - to the same project - well, it creates chaos. And chaos does not mix well with collaboration.
Why TWO Spaces???
If you accept my premises above, this explains why the JS community felt the need to implement some kind of standard for indentation. JS devs the world over were using a hodgepodge of different tools with different defaults. No one had a consistent idea of the "right" indentation. And once you start collaborating on that code, things get... messy.
But that doesn't tell us how we ended up, very specifically, with TWO spaces. Not four spaces. Not tabs. But TWO spaces. My readers (either of them) can correct me on this, but I'm not familiar with any other language that adopted two-space indents as a de facto standard. So why is that the de facto standard in JS?
This is where I point my bony finger of guilt, not at jQuery, but at Git. Git was released in 2005. In other words, it was released only shortly before jQuery. And for the web/open-source community, it quickly became the go-to solution for team-based code collaboration.
But I'm not focused so much on Git, as I am on GitHub. You see, Git is just a command-line tool. (Yeah... there are various GUIs for it now - but for most of its life, it's been, almost exclusively, a command-line tool.) When you're using that command-line tool, you probably aren't paying much attention to which files use 2-indent spaces, versus those that use 4-indent spaces, versus those that use tabs. You're just crossing your fingers and hoping for no merge conflicts.
Git Hub, however, is a different beast altogether...
GitHub was one of the first tools that allowed distributed teams to easily browse everyone else's code, and everyone else's branches, in the ever-present viewport that we've all come to know as a "browser". There probably were some other source control tools at that time that allowed you to peruse others' code on the web - but I'm not aware of them. GitHub was the first time that I remember logging into a web-based portal and browsing through commits.
GitHub was released in 2008. In other words, by the time that GitHub first started to gain massive traction amongst the digerati, jQuery was in full swing, and true honest-to-goodness professional JS dev teams were starting to collaborate over the web.
Why do I connect the rise of GitHub to the implementation of 2-space indentation?? Well... have you ever looked at tab-indented code files on GitHub? As a web-based client, GitHub used the default representation of tabs in HTML. In other words, GitHub always displayed tabs as taking up 8 spaces.
Furthermore, since many people were (and still are) writing JS in relatively-narrow viewports, I believe there was this natural pressure to make the code as "skinny" as possible. In the width-restricted world of web-based portals, even a luxury as simple as a 4-space indentation can feel unwarranted.
No one likes scrolling horizontally. And web-based portals are too-often squeezed into narrow viewports. So, from this perspective, it almost seems natural that the JS community - children of the web - would coalesce around a 2-space indentation standard.
To be clear, I'm not asking you to agree with me. And I'd love for someone to "set me straight" on this. But as far as I can tell, I truly believe that GitHub, more than any other factor, is responsible for spurring the 2-space indentation standard that we see today in sooooo many JS projects.
2-Space Frustration
Despite my (well-earned) cranky-old-guy reputation, the fact is that I do not lay awake at night gnashing my teeth over tabs-vs-spaces. If you haven't figured it out by now, I really prefer tabs. But no one really gives a s*&t what I prefer. And I get that. So on most days, on most projects, I just allow the editorconfig file to dictate to me how my code will be formatted - and I move on.
But this is my blog. And my readers (both of them) deserve to get a healthy dose of my whining and griping. So FWIW, I'm gonna close by pointing out some things about the 2-space indentation standard that make me frequently bite my tongue.
Accessibility
Oh, man... I hate having to spell this out, because it just proves how friggin old I've become. But the more JS code I look at, the more it's clear to me that these two examples are not the same:
// Example 1
const doSomething = (trials = 0) => {
for (let i = 0; i < trials; i++) {
const data = getTrialData(trial);
if (data.length) {
const filteredData = data.filter(datum => {
return getConstant(datum.someProperty);
});
}
}
}
// Example 2
const doSomething = (trials = 0) => {
for (let i = 0; i < trials; i++) {
const data = getTrialData(trial);
if (data.length) {
const filteredData = data.filter(datum => {
return getConstant(datum.someProperty);
});
}
}
}
If you look at those examples carefully, you'll quickly realize that there is no functional difference between them. They both have the same code. The only difference between Examples 1 & 2 is that Example 2 is indented with 3 spaces. Example 1 is only indented with 2 spaces.
Why does that matter??
Well... it probably doesn't - to you. Unfortunately, I can tell you with absolute certainty that it's harder for my eye to follow the nested logic in Example 1 versus the logic in Example 2.
I've been through this 1,000 times. I've adjusted 1,000 different settings in my IDE. But no matter what I try to tweak, there are still times when my eye gets "lost" trying to follow nested 2-space indentation.
When I've been in codebases that used tabs, this was never a problem. Because I could set my own personal IDE settings to display tabs at any width that was comfortable for me. But when a file uses 2-space indentation, I'm pretty much stuck viewing it in the exact same way. And I'm pretty much resigned to having to spend more time reading and understanding the code.
For me, there's just something about having that extra space in the indentation that makes it sooooo much easier for me to read. Unfortunately, the "powers that be" that want to impose 2-space indentation upon all of us couldn't care less. In fact, more than a few of my coworkers have been downright dismissive and insulting when I try to explain this to them.
Antiquated Comparisons
When I've been foolish enough to talk to someone about tabs-vs-spaces, I can't tell you how many times I've run into this (completely antiquated) idea that tabs are somehow ridiculous to view. In other words, they're still subconsciously referring back to the way that tabs are rendered, by default, in a browser (as in, when they're viewing the code in a GitHub browser window).
Even though they claim that tabs are just oh-so-horrible to visually parse, they can't show me how these tabs look so horrible on their screen. This happens because, on their screen, they're viewing the code in their IDE - and their IDE does not display tabs as taking up 8 spaces.
In fact, I've noticed over the years that almost all code reading happens on a dev's individual screen, in their IDE. In other words, they almost never see tabs represented as 8 spaces. But they still seem to have this vestigial distaste for what might happen if they ever chose to view the code in a browser window.
Tool Ignorance
I know there was a time in GitHub when mixing tabs-and-spaces could cause havoc. Specifically, it could drag you into a morass of merge conflicts. But I've noticed that a shocking number of current-day devs really have no idea of the inner workings of Git. Specifically, they seem to assume that any whitespace change will cause a merge conflict - or will screw up their code reviews. Of course, these same devs typically misrepresent what Git can currently do.
A few years ago, I was working with a guy who was a complete, pedantic, Grade-A jerk. I'd submitted a pull request (on a section of code that he never would have any reason to touch) - and he declined it.
What was my offense? The files contained tabs. He threw his hands up in the air (literally) and said, "There's no way I can review this. Because the diff thinks that you've changed every line in the file."
I replied to him, "The diff says I've changed every line in the file after you've told it to ignore whitespace???" He looked at me with that perfect blend of annoyance, and confusion, and exasperation. I honestly think it's the first time he'd ever realized that there was such an option in GitHub.
But the issue really had nothing to do with GitHub's "ignore whitespace" option. The issue had everything to do with the fact that my code had a tab in it - and he was gonna teach me a lesson.
The Stack Overflow Curse
By now, we've all seen the reports. Some years ago, Stack Overflow, in the midst of their broad all-dev survey, "discovered" that devs who use spaces make more money than devs who use tabs.
Honestly, that one "study" has caused more headaches for me than they could ever imagine. Suddenly, every snot-nosed junior dev who used spaces could look at me with some smug holier-than-thou expression and say, "Well, you know... devs who use spaces are paid more."
The problem is that those snot-noses can't tell you why they're paid more. They want to believe that the mere act of using spaces-over-tabs somehow makes you more valuable in the workplace.
No one ever stopped to consider that, for the last decade-or-so, "frontend" development (which used to be dismissed as somehow "lesser"), has moved to the forefront in many job marketplaces. And since JS now, for quite some time, has already adopted space-based indentation as a standard, it only stands to reason that they are getting paid more.
They're not paid more because they use spaces-over-tabs. They're paid more because they have a skillset that's in higher demand - a skillset that's just-so-happened to have coalesced around space-based indentation. But don't try explaining that to any of the sycophants who want to sing the holy praises of 2-space indentation...
Conclusion
In the end, I don't really think this article has anything to do with tabs or spaces or any other standard for indentation. My deeper interest is in how trends blossom and take hold. How they proliferate. How they become "standards" - even at times when there is no empirical evidence to support them.
I understand (I really do) that, sometimes, you just pick a "standard" - any standard. Because it can be preferable to having no standard at all. But after a quarter century in this game, it still sometimes frustrates me to see the haphazard way in which certain standards are adopted - and others are thoughtlessly discarded.
Oldest comments (72)
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)
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.
"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 ;-)
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!
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.
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
emojicode.org/
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)
Excellent post, really.
Thank you!
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.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.
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.
I always blame POSIX in in-person conversation, because nobody will bother to look it up.
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.
I’m one of those horrible tabs and spaces people. What can I say, my fingers have a mind of their own.
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.
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.
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...
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.
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 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.
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 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.
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 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.