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
“Error: syntax error on line 1”
…shit
Great, no scrolling through thousands of lines to find the right one!
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.
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?
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.
There’s a difference between doing something that’s “easier” and what’s right.
The way I see it, there are two competing strategies for improving the experience for braille screen users: making tabs more widely used and improving braille oriented editors. Without knowing for sure, my guess is that improving editors is a better strategy and this is in part because it is easier.
As a matter of principle it might be “more right” for people without visual disabilities to adjust themselves to people with visual disabilities than vice versa, but I also think that it’s important to care about what is actually likely to improve braille screen users experience and not default to the more principled goal without any consideration for how realistic it is.
(Of course, I might be overestimating how easy it is to get better braille oriented editors, but since you referred to this as the “easy” solution it doesn’t sound like you’re disputing this specifically.)
Of course, I might be overestimating how easy it is to get better braille oriented editors
A braille display traditionally is a personal, almost handfitted (estimated by price) device controlled by its screen reader software. Not the editor. This has some unfortunate implications:
- There is no (standardized) API to control your braille device directly. You could hand your screenreader filtered data, but that would be read as well. At best, you might be able to script your screen reader software to a varying degree of success. However:
- Every aspect about this is extremely abysmal in every possible way, so it will likely require you to fork over some biiiiig amount of cash to one of the vendors to provide a brittle plugin. In particular if we are talking about JAWS. Think of extremely unstandardized COBOL dev with less stability and more price gauging involved.
- As far as free readers are involved, only the proprietary and licensing aspect go away. Still, developing extensions is terrible in many ways. For example, for ORCA, I was able to find out that you can extend it somehow. Alledgedly. NVDA on the other hand has better documentation. That is to say, it has documentation. Now, you might recall that NVDA is written mostly in Python, and its devs rightly don’t even pretend that one could develop stable software in Python, so APIs might change. However, I wasn’t able to find a Filter function specific to braille output. That’s likely because
- From my superficial experience, developers of screen readers think of braille displays mostly as an alternative to speech. It even took them quite a while to be smart about not displaying redundant, long lines of text.
So yes, you might be overestimating how easy that is, compared to telling some diva asswipe chucklefuck to use that formatter or work at McDolans.
Thank you for the insight, didn’t expect it to be that dire. Tabs and spaces nonwithstanding, hope that the screen reader/braille display tooling situation improves in the future, sounds like it is sorely needed.
I sure hope so, but I’m not overly optimistic tbh. The market is basically considered medical, therapeutic devices. It is as you imagine, probably worse. It isn’t easy to find prices directly, but the only way this range of vendors continues to exist in this niche market is to sell devices with the complexity of a keyboard for four to five digits. There is no competition worth talking about happening.
So unless very specific regulation takes place, I don’t see standardized access to braille displays happening.
- There is no (standardized) API to control your braille device directly. You could hand your screenreader filtered data, but that would be read as well. At best, you might be able to script your screen reader software to a varying degree of success. However:
Let’s agree that we aren’t going to affect this change in this comment thread, so which one is more “pragmatic” is beside the point.
What does matter is whether we decide to have an inclusive view on this issue, and are willing to make extremely minor modifications to our settings and workflows to be more accommodating for others.
I am encountering more and more cases where people behave in inexplicably selfish ways, and this just feels like another one. It’s low/no-cost to do, yet could yield benefits to others. Low cost/risk, high potential reward.
Starting with “we’re not going to even consider raising awareness and let the market decide” is just a very cynical way to approach the world, and I’d argue is even actively harmful to the people that hold that view.
Do you think it matters if getting a large number of people to switch to tabs is an achievable project at all? Maybe I am a bit cynical but this seems to me like something that is actually very difficult to do.
When faced with a problem like this I think it makes more sense to approach it from a perspective of what would be a practical way to actually address it and refusing to do that does I think in its own way betray a different kind of cynicism.
For the record what I’m saying isn’t that I wouldn’t switch to tabs for the sake of people with various disabilities, I’m saying that spaces are slightly better than tabs if you don’t have any relevant disabilities so if there is a way to have the cake and eat it to that would be a nice bonus, but that’s honestly besides the point.
You are treating this as a binary/zero-sum game. Will we get to 100% use of tabs (or spaces)? No. Will we get a “perfect” viewer made and then adopted by all visually-impaired people? No. Making people aware that a fairly mundane choice has a negative impact on others might change their behavior, or at least challenge it.
Change like this is incremental, so just having the conversation, and asking you to consider that making a small change to your config might help some people down stream is something. Asking you to bring this point to the next conversation about tabs vs. spaces, is helpful.
I’m saying that spaces are slightly better than tabs if you don’t have any relevant disabilities
This is my fundamental issue with your original statements, and this thread: It’s a subjective choice that you think is slightly better than removing a barrier/major annoyance for an entire group of people that may want or need to interact with your code. It’s closing the door on possibility for a minor personal preference.
deleted by creator
This is the attitude that’s needed 👍
Yeah. It is depressing.
I’ve always wanted an accessibility feature that uses haptic feedback to mimic braille patterns for reading purposes too.
In general a lot of creative stuff can be done if we focused on it even a tiny bit more.
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.
Yesterday, I shared some spicy takes. A few were particularly controversial—most notably, that I correct Gif the correct way (with a soft G)
And I stopped reading there.
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.
If the original dev intended to make their code less accessible and their project less inclusive in favor of eye candy, they should rethink their priorities.
I think calling one way better than the other is flawed. The reason the title is saying that tabs are objectively better is because they are used in addition to where spaces are used elsewhere. You could make the same argument in favor spaces due to keeping things simpler.
The argument of having variable indent size for tabs so viewers can decide how big they are is imho legitimate but also not the goal as it’s addressing something that teams generally agree on. There is max characters per line, brace placement, general code style and rules. Yes we can eject the indentation from the rules that are agreed on but once again simplicity over complexity has an equal say.
In the end it doesn’t matter that much, a good programmer will be able to work in either setting, the Editor will do most of the work anyways.
With all that said, spaces all the way!
This is a holy war that I will gladly fight again and again! I can’t believe that soft tabs are more popular, especially in python!
That is because they are superior.
spatium vult.
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?
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.
Well written code doesn’t have an implicit tab size. You should be using a tab to mean “one indent” and if you need to align something an exact number of characters then use spaces.
This is the downside to tabs, they are easier to use correctly. With spaces if it looks right in your editor it probably looks half decent everywhere else. Tabs have a worse behaviour if they are misused, but if used well then every viewer can view and edit with their preferred indent size.
I wonder if it could be possible to adjust the “indent number of spaces you see” in code editors.
You could potentially do a good job with a full parser for the language in question to determine the indent level and separate indent from alignment. But I’d rather not rely on this when we have a perfectly simple and semantic character for indicating what is an indent and what is an alignment.
Maybe this could be a useful linter though. That way mistakes are caught but not every editor needs a perfect parser of every language.
The thing is - I have probably seen hundreds of projects that use tabs for indentation … and I’ve never seen a single one without tab errors. And that ignoring e.g. the fact that tabs break diffs or who knows how many other things.
Using spaces doesn’t automatically mean a lack of errors but it’s clearly easy enough that it’s commonly achieved. The most common argument against spaces seems to boil down to “my editor inserts hard tabs and I don’t know how to configure it”.
why don’t we store code unformatted and have everybody’s IDE display it with their preferred format applied? it would make everything easier and stop people bickering over pointless things.
Storing an AST would be interesting, but it’d require the IDE to support parsing each specific language, so you’d probably want something like an LSP but for just parsing to handle that.
laughs in lisp
Nah, I’ll keep on sticking with spaces or whatever the language’s formatter uses. Ain’t no way am I mixing tabs and spaces, will just stick with spaces.
Seems there’s not much else going on
Tabs take less space (space as in space in storage, like free as in freedom) tbh.
My disk is almost full! Better switch to tabs for indentation!
Happened to me quite a few times, relatable situation.
Original poster is right by all accounts, of course. Now, let’s come up with exotic significant indentations.
function xyz(a, b): | var x = 2 | if true: | | do_something() | else: | | do_something_else() | anyway()Pro: Your editor no longer needs to implement indentation hints.
Con: Looks obstructive if not highlighted like an indentation hint.
Your turn.
Right, that is another item I wished more editors would have picked up. Besides - say - nested language modes.
Honestly, my editor (Neovim) just picks between tabs and spaces for me, so I just end up using whatever’s already there. The only language where I’ll explicitly use one is Haskell, just because spaces there allow me to keep everything nice and lined up.
