I’ve always wondered why some people tout “forcing a consistent appearance across environments” as a pro for spaces. That’s a bad thing.
To be honest I’m surprised code format converters aren’t ubiquitous. Let the repo have it’s master format, enforced on commit. Then converters translate into each developer’s preferred standard dialect on checkout and back again on commit.
The argument for having tabs adjust depending on your ide sounds better than it is in practice. Someone formatting code to look nice with width 4 will look horrendous for someone who uses width 8.
Spaces makes it uniform and captures the exact style the original dev intended
If you have your tab width set on 8, that is on you. You will also set your IDE to insert 8 spaces when you press TAB and I will cry when I have to give you a code review.
When I indent my code, I am indicating that I am in a nested block. I don’t care if, on your screen, that indent is 2, 3, or 4 characters.
Anarchist: tab with set to 1
That’s fine, when I view it I will get my preferred tab width. This situation is only anarchist with spaces, with tabs they are just a masochist.
Tabs for indent, spaces for alignment. This is the way, I can’t believe people are still fighting that ?
Anything for indent (barely matters, as long as the editor forces it to stay consistent), and fuck alignment, just put things on a new line.
struct Ident arr = [ { .id = 0, .name = "Bob", .pubkey = "", .privkey = "" }, { .id = 1, .name = "Alice", .pubkey = "", .privkey = "" } ];Not like that, lol
Just saying, instead of this monstrosity
CreateOrderRequest(user, productDetails, pricingCalculator, order => order.internalNumber)Just use
CreateOrderRequest( user, ...Putting the first argument on a separate line.
Same if you have an
ifusing a bunch ofand(one condition per line, first one on a new line instead of same line as theif) and similar situations.When I talk about alignment it’s not about function arguments, but values, “=” signs and such. You simply cannot use tabs for that because alignment must be fixed and indentation independent:
CreateOrderRequest( user, productDetails => order.detail, pricingCalculator => DEFAULT_CALCULATOR, order => order.internalNumber)
Another accessibility reason for tabs: when using a braille display, each space takes up one character cell, so indenting with four spaces eats up four cells. Indenting three times with four spaces each eats up 12 characters already. Tabs only take one character cell each, so three indents = three character cells used.
The fact that there (I assume?) isn’t a braille oriented text editor that can handle space-based indentation in a smarter way is a bit depressing. Maybe the solution should be better tools based around accessibility rather than convincing everyone to switch to tabs, which is a project that will just never succeed.
rather than convincing everyone to switch to tabs, which is a project that will just never succeed.
Few years back, Coraline Ada Ehmke went on a one person crusade opening a pull request on every major Github repository to adopt a code of conduct for the project, detailing the complex rules of how the humans in that microcosm of a project should interact with one another. Today, it’s the norm.
Arguing that it’s invincible to convince people at large to adopt tabs over spaces with good arguments is a ridiculous statement. All you are doing is making up excuses for not having to care.
Neither tabs or spaces are good. The correct way is to leave no whitespace in the code at all. It’s unnecessary and adds to processing time.
Everyone should aim for 1LOC per commit
My program, written in the whitespace language, ruined.
CURSE YOU PERRY THE PLATYPUS!
“Error: syntax error on line 1”
…shit
Tabs let you define how big you want each indent to be
…except when they don’t. Many common environments have a hardcoded tab size of 8, which is insanely big for using it for indentation.
As an embedded software developer that does linux kernel drivers I’ve come to love the tab size 8 indentation level.
I’m paraphrasing: “if your indentation level gets too deep, it’s time to rethink/refactor your function.”
And with tab 8 you’ll notice it rather quick if your function does too much/unrelated stuff.
A function should be short and do one thing only, if possible. It also makes unit testing easier if that’s a requirement.
When you’re operating on such a low level of abstraction, it’s no wonder you don’t need deep nesting.
Interesting take. I prefer spaces because each piece of code that I see with tabs has an implicit tabsize you really need to have if you don’t want the code to look ugly - especially if the person has been mixing tabs and spaces - and they usually do. Sometimes unadvertently.
When you remove all tabs at least everyone is on the same page.
To the actual problem raised by the article:
I have ADHD. Two spaces per indent makes it damn near impossible for me to scan code. My brain gets too distracted by the visual noise. Someone who’s visually impaired might bump their font size up really large, and need to scale up or down the amount of space per indent. Someone might just prefer it because…
I wonder if it could be possible to adjust the “indent number of spaces you see” in code editors. Code editors are able to figure out what are indents and what are not, so in theory it should be possible. Perhaps that would be an idea for a new feature?
I consider tabs for indentation a failed concept.
The idea is good, but it evidently failed. Most guidelines and newer Tools recommend or require or use spaces for indent. They have their reasons too.
The prevalence of spaces makes it hard to make a contrary argument for tabs. By now, I don’t think it’s worth even if it had reasonable advantages.
Editors/IDEs that parse syntax can adjust space indent too. A mixture for indent and alignment is not obvious for everyone (I always display whitespace in my editors and am deliberate and consistent, but many people and editor defaults won’t be). Some defaults of four or eight space-width tab display is atrociously wasteful and inaccessible.
Spaces are a good enough baseline. It works well enough. And most importantly it works consistently. That’s why it won in prevalence and use.
