I've got 99 problems and "spaces VS tabs" actually is one of them!
I find it embarrassing for the entirety of the programming, developers, and designers worldwide industry and community to still have these kind of debates in year 2015!
We laugh about medieval people thoughts, modern bigotry, or how stupid is from time to time the rest of the world around us ... and yet we cannot stop whining about spaces or tabs.
Moreover, the untold story about this debate is that everyone is simply being selfish and every rationale behind is made of opinionated and volatile fluff that does not match current real-world scenarios (yeah, maybe me too, but before that, please keep reading 'till the end, thanks!).
Defining a Standard
There are few standards and protocols universally implemented in the programming world and JSON, as well as XML, are just a few and rare examples.There is no "my XML is better than yours" or "my JSON looks nicer" discussion there, as soon as you write something not conforming with the standard you are causing troubles either to your own code and yourself or to whoever needs to consume your code!
There's not "but ..." or "because my style ..." here, there is only one way everyone understands which is the only compatible way and the best way to move forward.
Unfortunately, in the history of Computer Science (funny it's called Science in this case) there's still no agreement on the "spaces VS tabs" matter.
Fact 1: Nobody wants horizontal scroll
Not only books are read vertically since ever, "technological mouses" are not even created to simplify such task and on top of that: if you don't set yourself a limit to the amount of columns your code should actually warn you, usually 80 up to 120 chars, it doesn't actually matter what choice you made to your indentation because "'yo column is so wide I though you were a code cruncher instead of a human being".We don't like to scroll horizontally and we would like to be able to put 2 or more different files beside each other to compare diffs and lines in a single screen ... right?
In other words, it's OK to have 80 to 120 chars column width limit because we all agree it's needed!
Then we have either developers that connect via SSH, those that use daily vi or vim, and people on Smart Phones that maybe are surfing online, studying some piece of code where they also have to scroll every single pre tag because by default each browser uses 4 or 8 spaces to represent a tab ... you say no?
This is something standard to show to you, it doesn't have any special parsing behind, it's just plain code.
// 2 spaces indentation random code
class View {
constructor(options) {
this.model = options.model;
this.template = options.template;
}
render() {
return _.template(
this.template, this.model.toObject()
);
}
}
// its tabs based equivalent
class View {
constructor(options) {
this.model = options.model;
this.template = options.template;
}
render() {
return _.template(
this.template, this.model.toObject()
);
}
}
Before asking ourselves which piece of code looks universally better, I just would like to show you a couple of cases different from your editor of choice scenario:
Even if the code is very simple, the console needs to be width at least 60 chars because that's how big the non standard tab is visualized in there.
I don't even have any idea how to shortcut the horizontal scrolling on a console in case the code would be slightly more complex than that!
In the second case I'm just using a Samsung Galaxy A3 phone with its HiDPi 540x960 pixels 4.5" screen that is good for pretty much everything beside reading online code that used tab indentation.
Common reactions to the "need to horizontal scroll" problem
- people that read and write code for living have big screen (plain selfish)
- nobody reads code on their phone (disillusioned and selfish)
- who uses
vithese days? (ignorant, disillusioned and selfish) - most Website normalizes code and pre tags to highlight shit and they all use spaces so this is a non issue (do you even read yourself? you just confirmed they have to normalize your code into spaces ... selfish is not even the right term here but I don't want to offend anyone in this post)
Fact 2: Tabs are not standard
Or better ... standard as ASCII char but not standard as visual behavior.Even if this is like stating the obvious, if I setup my editor to kill tabs or spaces and replace it with tabs or spaces, the source code will be inevitably different and in some environment compromised.
Yeah, we can all setup hooks that automatically make the source code universally compatible ... and have you ever wondered what kind of fallback that hook will do? I give you a hint, tab key is not standard, meaning the wiser choice to normalization would be spaces (once again) because spaces are universally looking the same.
If you are thinking "these normalization hooks exist ... so why cannot we just standardize them" it's again you being selfish because you are asking everyone to inevitably add a toolchain to deal with, and only in order to add such standardization.
"yeah, come on .. who doesn't have a toolchain to deploy these days?" ... you like that disillusioned and selfish feeling, don't ya?
Fact 3: No real-world size saving
Since I've just somehow bullied those thinking everyone have a toolchain to deploy their code, I'd like to apologize for those developers that only know Front End Web Development and, accordingly, think the rest of the world does the same thing they do: using babel or some minifier/code shrinker plus for sure gzip or deflate to server their files.Yet in disillusioned land, these people are kinda right about the Web: if you do web development you need at least one of the previous steps in order to serve a web page and the most common/deployed way out there is gzip or deflate compression for static file serving.
Just as reminder: while minifiers will remove all spaces making this debate pointless, what are gzip or deflate good at? Compressing within each predefined chunk of bytes repeated information. In case this still doesn't ring any bell, it means your multiple white spaces won't be relevantly heavier, in term of size, than any other file based on tabs.
These kind of believes come from 10 years ago and from Web oriented developers, where implementing
mod-deflate on Apache was painful because it was requiring powerful machines and stuff ... well, this post title includes not by accident the end of the current 2015 year where machines like Rasberry Pi can serve gzipped compressed files without hiccups. Perhaps it's time to update our believes about Web technology and stop thinking the most common char in our code, either a space or a tab, would save the world from data-roaming costs? 'cause that's not happening and is a misleading achievement!
Fact 4: You don't see any difference anyway
After some myth busting it's time to get real on the matter and think about the following points:- if you are settings in your editor tabs to visually look and feel like 2 spaces, you are simply proving 2 spaces are the way to go and you are being selfish and stubborn about this discussion lying over your own arguments and lying to your own eyes. Please stop!
- If you are absolutely in love with your indentation, please remember there are other people that might read your code. If you don't care about them, that's OK and it's just you being selfish ... otherwise you have to explain to everyone why you want them to horizontally scroll in their screens that are not made to read your code created in the latest 4K display
- if you have some common sense please check the reading difference with previously posted images and try to figure out if you can live with that, contributing in making 2 white spaces indentation a standard for the rest of the world (like it is already for most developers)
Fact 5: You cannot always configure the editor
If you are one of those developers thinking "configure whatever software you're using to set tab width to whatever you want" I'm afraid you are in the disillusioned and selfish zone too. You don't necessarily own the environment you are trying to read or edit, and if you use SSH you don't have any idea where configuration files could be forvi or vim textual editors.Moreover, you are considering you as the only member of the team with the right to eventually setup remote rules for the editor, ignoring developers that, before or after you, had the same role or privileges you have now.
How selfish, short term thinking, and waste of time for everyone in the long term would that be?
The alternative: stick with a standard: decide today 2 white spaces when tab is pressed IS the standard and you'll never regret such choice any time you'll find yourself in the same situation you just created: "2 spaces? fair enough, let's move on!"
Counter fact: Tabs mean Freedom
As soon as I've published this post I've been storm-tweeted about the following argument: if you use a tab, everyone can configure in their editors how that should look like so that everyone is happy and the indentation scale accordingly with the screen and habits you have.I'm all for freedom and by no mean this post want to be some classic dogmatic dictation about spaces and all I am trying to tell you is that we are going nowhere with this freedom. Think about standards again, like I've said in the first paragraph, and the fact nobody has to argue their style is better.
Think about standards and realize everyone can read JSON or XML without doubts about the fact they are reading and writing it right for anyone else.
Think about the fact most common devices will still show tabs like 8 spaces per line and the rest of the world will still need to horizontal-scroll by default whatever code you wrote.
Think about the fact tools could do the exact same basing their behavior on a standard, instead of having to deal with possibly hybrid indentations and eventually figure out if that should have been tab based or spaces based ...
Think about the fact these kind of CSS problems exist only because we don't have defined a standard yet ... these are tab related problems meaning if we all agreed on using spaces nobody would have wasted much time to fix that.
Think about the fact I am 100% sure that if I show you the following:
"the following"I can predict exactly where it will be shown on your screen and how it will look like on any monospace like font ... can you do that with tabs?
Think about the fact it's tough to change indentation habit but with all problems we have to solve daily that's actually going to be the least problem we've ever had since the editor indeed would make the transaction immediatly productive ... and think about the fact after that, every new, modern, and even jurassic text visualizer will simply show text the way we meant, with a standard indentation and possibly compact enough to horizontally fit in a 320x200 screen.
Think about the fact ASCII art could never exist based on tabs so ... honestly: do you really want the freedom for yourself to have never any idea how whatever you write might look in another screen?
As Summary
My wise grandpa would have surely solved this problem in like few seconds:"I dunno much about programming but which indentation works the most?"
The answer would have been "spaces works for sure" which is just a partial answers ... but it would have been enough to set the deal.
"My" last point is that spaces will always look like spaces because nobody configures them to look differently.
Tabs? I could configure them to look like 2 spaces and you, thinking your tab indentation with 4 virtual spaces is universal, will probably instantly feel pissed off.
Please let's STOP all together THIS MADNESS 'cause 2 white spaces facts easily win over every other habit or argument.
Thanks for reading yet another opinionated post about this battle ... I'm actually pretty sure nothing will change after this, hoping I'm 100% wrong!
