Why Tabs Are Better for Indenting Code?
Using tabs or spaces for code indentation can lead to passionate debates among developers. While both methods serve the fundamental purpose of structuring code, there are compelling arguments as to why tabs emerge as the better choice for developers. Let's take a look at why tabs offer distinct advantages over spaces when it comes to code indentation.
User Preferences:
Customization
One tab character corresponds to one level of indentation. You can change tab size in your own editor without breaking indentation.
Collaboration
Each teammate, contributor, guest reader can view the code as they want.
Enhanced Accessibility:
Different needs
Keep in mind that visually impaired people have different needs and only the tabs allow them to set their preferences.
Refreshable braille displays
Each space wastes one braille cell and takes away valuable braille realestate. This means that 4 spaces for 1 indentation is 4 times more painful than 1 tab for a blind programmer.
Further reading: Addendum: tabs for refreshable braille displays
Reduced File Size:
Storage space savings
Since tabs are represented by a single character, they take up less space than the multiple characters required for spaces. In large codebases, this reduction in file size can result in significant savings in storage space and faster file transfer times.
Better for the planet 🌱
Additionally, smaller files help reduce CO2 emissions by decreasing power consumption during data transmission, storage and device operation. By adopting tabs, you can play a crucial role in minimizing the environmental impact of digital technologies.
Consistency:
Tabs ensure consistent indentation levels across different text editors, Integrated Development Environments (IDEs), and programming languages. They maintain uniformity in code formatting regardless of the user's environment or editor settings.
Conlusion:
Using tabs for indentation instead of spaces can enhance user-friendliness by providing customization options, ensuring consistency across environments, reducing cognitive load, and promoting accessibility in code development.
I'm in Team Tabs for all these reasons.
Top comments (14)
To be fair, the amount of bandwidth saved by a company using tabs instead of spaces for code indentation probably doesn't even approach that used by one site visitor loading this post.
Oh, I commented before I remembered what I was going to add: your editor should be able to switch between spaces and tabs, so if you personally like spaces, then it will use those, but convert back to tabs when you save. Or when you commit, or whatever.
Or more simple, your editor lets you set how large a tab is ( : I have mine set to 3, because 2 felt too small and 4 was too large.
I suppose the distinction matters if people use the Space key instead of the Tab key to indent code, though even when I was using spaces I always used the Tab key to indent.
Thinking about it I very rarely use anything to indent manually. The editor does it for me and if I want to shift the indentation of a block I'll use something different there as well.
Ah, I just remembered a formatter like Prettier would automatically take care of all that, and I don't have that on every project which is why I still manually indent every once in a while.
You're right, the editor takes care of most of it. I mostly find myself adjusting things when either copying and pasting or dealing with multi-line strings.
Indeed, you are right, for local and individual use, it has little impact!
But on a global scale, it’s something else and each individual action is important!
Let's take a concrete example: Worpress.
The current version 6.4.3 has 1,385,052 indentations using tabs.
The total uncompressed weight is 69.7 MB
If we replace all tabs with 4 spaces, then we get 1,385,052 * (4 - 1) = 3,975,156 bytes
WordPress is therefore 4 MB lighter by using tabs instead of 4 spaces per installation of this CMS.
With more than 40 million WordPress sites, we can estimate the overall gain at 152 TB.
That's huge!
It would be interesting to know how much 152 TB costs in energy and carbon footprint.
The key word there is "uncompressed" :) Nothing is regularly sent over the wire in that format - and once the wordpress zip file is unpacked, 99% of those files will sit there doing nothing anyway.
Still, you're right - if everyone optimised everything they could, the world would be a better place!
While I am on the same team as you for mainly the same reasons, you neglected to address the arguments of the other side:
With spaces, you ensure the same formatting without the need to set up different editors and IDEs.
Since the code is usually stored and transferred in a compressed format, the difference in size is negligible.
Yes, but in this case of spaces you get a strict style guideline. It lacks flexibility for user preferences and accessibility when working on a collaborative project.
About compression, do you think a website running PHP has minified files? The code is still on the server and using more disk space.
I guess... has anyone actually done the math yet?
I suppose a claim of "significant savings in storage space" requires backing besides just the difference in number of characters, since real-world file storage is more sophisticated than storing bytes as-is.
If anything, it makes me curious on if there are savings, how much is it really?
Just did some maths with latest version of WordPress: dev.to/cyrez/comment/2d723
As I said, I'm on your side. I just think that if you do not show the arguments of the other side, your argument falls flat.
If you are running PHP, chances are it is running on apache2 or in some cloud environment. If you can't setup mod_compress or whatever equivalent is used in the cloud (which usually is one configuration switch), then storage is probably the least of your issues.
There is of course some optimization possible but the code remains stored statically initially.
In a world where open source is important, user preferences and accessibility seem sufficient reasons to me. ;-)
Tabs vs Spaces to me is just bike shedding.
Yes you're right! No debate. Tabs are just better ;-)
About 1.
Why not use tabs that natively respect user preferences?
About 2.
Have you ever contributed to a large open source project such as a CMS?
With hundreds of contributors, you need code standards and clarity for a good contributing ecosystem.
About 3.
I think this point is out of context. Using spaces or tabs has no side effects on understandability, while limiting variables and names to 3 characters or less, as you suggested, is really extreme. The main goal of code is readability, structure, and accessibility. Using less disk space is just a bonus, although important!