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.
Because other people might have restricted environment which might not suit their preference is not a good reason to level it down IMO.
Also, I think 9 is the best size for indent (matter of preference), do you think I should switch to space so everyone can enjoy this wonderful view I have ?
It’s not just “might”. Termux is pretty much the only good choice for programming on Android.
I think 9 is the best size for indent (matter of preference), do you think I should switch to space
I think you should switch to an exorcist.
What’s your point ? You can use vim on termux and set the tabsize to whatever you want for example.
What environment are you using that has a hardcoded tab size? I haven’t seen this since typewriters.
Some projects just use tabs as a compressed form of 8 spaces. But that is a sin. Use tab to mean “one indent level” and align with spaces if you need to. (the occasional ASCII art diagram)
What environment are you using that has a hardcoded tab size?
- Termux
- SourceHut
- “View page source” in the browser
Termux
I think running tabs -N (where N is you preferred tab size) in the terminal should work. This is what I use in my zshrc on desktop.
SourceHut
Yup, they seem to be pretty opinionated here. If you look at the source there is just an inlined style with a single rule pre { tab-size: 8 }. I guess that is what you get when you use opinionated tools. The user’s browser isn’t right, my preference is right!
“View page source” in the browser
On Firefox this uses my default tab size of 4. But I guess changing this default isn’t user-friendly.
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.
Oh, I’ve done my fair share of C++ and Python as well. But you got to agree with me that when you are on your fourth indented “if case” it’s time to step back and think about what you are trying to achieve. I mean it’s probably going to work, but probably also very hard to maintain that type of code.
This is the biggest problem with tabs. Too many tools don’t let you adjust the size (or make it very difficult). This is the only reason I usually prefer spaces (only very slightly).
My dream solution is elastic tabstops and I’ve posted about it here before a few months ago. The problem with wanting elastic tabstops is that it seriously compounds the issue of “editors don’t properly support it”
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.
So your fix is “convince all the people that want/need the better handling to use a specific editor?” - perhaps it’s a smaller number of people, but do you not see the irony there?
I honestly don’t care about tabs vs. spaces, but if there’s a low cost change in my setup that makes it easier on others, why not?
My spontaneous reaction is that making some sort of braille oriented setting for some or hopefully most editors used by people with braille displays (I have no idea if using a “normal” editor even makes sense if you’re using a braille display) is the most pragmatic solution to their screens being taking up by spaces.
First of all, convincing everyone to use tabs is a monumental task. Convincing people with braille displays to use more convenient tools on the other hand seems pretty easy, why wouldn’t you want to use more convenient tools?
Secondly, there is a large amount of code written with spaces today, so even if people switch with tabs in the future you might still want to be able to read legacy code.
Thirdly, I don’t think that the choice of tabs vs. spaces is completely arbitrary because of alignment. Using tabs for indentation and space for alignment leads to a lot more micro management of whitespace compared to just using spaces. I would guess that alignment isn’t very braille friendly anyway, but it does make the code more readable for other people. Having a good braille editor affordance might be closer to letting us have our cake and eat it too.
Of course, I don’t know what this would look like exactly, and maybe there’s some sort of obstacle that I’m overlooking, I do want to be clear that this is just of the top of my head as someone who has never used a braille display.
There’s a difference between doing something that’s “easier” and what’s right.
Whether there is more legacy code with spaces or tabs is irrelevant. Most of the code that will be written hasn’t been written yet.
I disagree with you on “micromanagement” of spaces vs. tabs, that is nonsense. Set up a formatter for commits and set your IDE to display how you want.
The pragmatic view on one or the other is that for a one group of people, using tabs appears to be significantly better, and for everyone else, it barely matters at all, except as personal preference.
That being said, I’m not vision impaired, so I don’t know what the preference would be.
The reason we’re even talking about it is that someone that has studied it from an accessibility perspective has asserted that tabs would be preferred.
That reminds me of those times when back on reddit some dev showed up to present their new GUI library. Bragging about how they were better than Qt devs etc. (even though they didn’t implement the hard parts, like working text fields or tables)
After some time a bunch of people had enough and started bullying those guys into submission about accessibility. After some time, every of those toolkits had support or at least plans for supporting screenreaders. Eventually, AccessKit became a thing.
Good times.
Arguing that it’s invincible to convince people at large to adopt tabs over spaces with good arguments is a ridiculous statement
I do actually think that it is very hard to convince basically every programmer of something, no matter how good arguments you have.
Also, without knowing much about the issue, it sounds a bit like the tooling for people using braille displays isn’t very good and fixing that is maybe also worth advocating for, perhaps it’s even a strategy for advocacy that is more effective?
I wish every language had a gofmt, this is such a non-debate (tabs are indentation, spaces are alignment)
And over gofmt, rustfmt lets you set settings for the project. Keeps the code looking how I want, and contributers don’t have to care.
The absence of settings in gofmt is a feature. The kind of basic formatting it handles is not worth having opinions about.
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!
Code formatter and run auto format
Holy wars are fun, but this is the answer.
At least this way the holy war takes place in commits to change the formatting file.
Unless go, in which case the holy war is now everyone who hates go format rewriting the code in a different language.
