Make codebase indentation accessible (by using tabs)

[davdroman]

I know, I know, the eternal developer debate. But please hear me out on this one before knee-jerkily dismissing it.

There are some very good reasons to prefer tabs over spaces.

Accessibility

This post makes an illuminating argument as to how in big companies, tabs are the more accessible option for developers with visual impairments that need to:

• Use tab-width 1 because they need to use gigantic font-sizes.
• Use tab-width 8 and a really wide monitor.

This thread makes an equally important point about the difficulties braille readers go through when spaces are used instead of tabs.

With the ever-growing size of Point-Free/TCA's community, I suspect a lot of developers aren't comfortable or even able to contribute to the project as much as they'd like to (or at all) due to the project's choice of 2-space indentation. I believe the project might be missing out on a lot of potential valuable contributions from people with visual impairments.

SPM and Xcode

While indentation options are configurable per Xcode project, SPM packages lack this setting, so they default to whatever the global Xcode setting is. Contributing to different open source SPM packages with varying space indentation preferences is a bit of a nightmare, as one must constantly switch back and forth between indentation widths in the Xcode settings panel.

Ideally, Xcode would support the EditorConfig standard to work around this, but that's up to Apple to implement and pretty much a pipe dream right now.

Running swift-format on main is a fine workaround to catch the odd miss-indentation, but relying on it entirely for consistency yields some pretty awful PR diffs from users who have differing Xcode indentation settings to that of TCA's.

Ultimately, I believe the only viable and clear-cut option to avoid these issues is to use tabs, and let the user use their favorite width seamlessly.

GitHub

"But GitHub always renders tabs as 8 spaces, that's too wide for me!"

It used to, but not anymore. Users are free to choose their preferred rendered tab width on settings (though admittedly keeping the default to 8 is a terrible move on GitHub's part).

---

I hope you can give this rational some consideration, and let me know what you think. I understand this is quite the can of worms to open, but I figured now that 1.0 is out and the community is growing so massively, it'd be a good time to revisit the fundamentals and make sure everybody is welcomed and able to contribute without silly obstacles like unsuitable indentation.

[Alex293]

TBH I never understood the debate, tabs were made to give the control to the user.

[acosmicflamingo]

The debate itself has to do with wanting full control over how your codebase will look since using tabs could mean that code that wraps at 80 characters mark when indentation is 2 spaces may now be wrapped even more when the tab has a width of 4 spaces, and there is no telling how readable the end result would be.

With that being said, I never realized that tabs were more accessibility-friendly, which certainly adds a ton of weight to the argument that a codebase should use tabs over spaces.

[Alex293]

Well that's exactly the point of using tabs, every body can have a different setting for tab width, so you can keep it short with 2 spaces but someone else can have it longer if wanted ; you can have your cake and eat it too. Obviously this requires that the software rendering the text allows you to choose the setting but most IDE do and GitHub so the debate no longer make sens.

One a side note, I'm more into 4 spaces but I'm changing toward 2 since Rx, Combine and SwiftUI use so much call chains.

[stephencelis]

While it's the point of tabs and great in theory, we unfortunately live in a world where in practice it doesn't typically work well out of the box. So we think it's probably more appropriate to lean on auto-formatters like swift-format than worry about providing a tabbing/spacing that fixes some problems but introduces others.

I wrote a bit more in this reply, but we'd definitely welcome making it easier for folks to reformat to their preferred style: #2340 (comment)

[stephencelis]

Hey @davdroman!

Thanks for the thoughtful discussion. We definitely agree in principle, but also worry that a change like this isn't as straightforward of an improvement in practice.

While using tabs solves accessibility issues in some cases, we risk introducing accessibility issues in others. The default reading experience on GitHub, for example, could be problematic. GitHub still says "8" is the default spacing for tabs in my appearance settings, and though I’ve changed it to "2", most developers will have it set to that default "8" or maybe "4": the first quite unreadable to most, and the second readable, but in a wonky way with regard to how swift-format columns are line-broken.

Most code and tooling provided by Apple uses or defaults to spaces, as well, so it's unclear how well such a change would work in your average user's setup: they clone a tab-based TCA but Xcode assumes 4 spaces, so the mismatch may introduce confusion when staging changes in Git and seeing diffs in your command line pager. Now maybe this experience is slightly better than the typical 2 vs. 4 space mismatch that exists today, but it's trading one problem for another.

At the end of the day we decided to go with the community via swift-format's default style. It removes a lot of the opinionated style-guiding, and it generally matches the standard library (which also has far more folks cloning/contributing than TCA, so I'd be curious what their solution for accessibility would be).

Now this isn't to say we can't improve the experience here. We'd be totally down for tooling and CONTRIBUTING.md instructions on how to reformat the library (using swift-format) to a different, preferred format for the purpose of reading/contributing locally. Since we automatically format things again upon merging, there's no harm in opening a PR with different spacing than what’s on main.

We won’t have time to work on such tooling ourselves immediately, but we’d welcome contributions to get the library there.

[stephencelis]

Also to directly reply to this:

Running swift-format on main is a fine workaround to catch the odd miss-indentation, but relying on it entirely for consistency yields some pretty awful PR diffs from users who have differing Xcode indentation settings to that of TCA's.

PR diff viewing can generally be improved by ignoring whitespace changes. It's not perfect but better than nothing.

Ultimately, I believe the only viable and clear-cut option to avoid these issues is to use tabs, and let the user use their favorite width seamlessly.

I just don't think editors are typically configured to work seamlessly and avoid these issues, but maybe I'm missing something? E.g. if Xcode is configured for spaces, the same issues you mention above will apply when contributing to a tab-based project.

[lyzkov]

In my opinion, two space-length indentations can be an excuse for overly nested structures. It has practical implications for developer experience, such as worse readability. With shorter indentation, I am less sure about the scope of the current line. Have you decided to go with a shorter indentation to decrease the line width for code listings and video presentations?