Refit: Feature: Source code switch from spaces to tabs

Created on 17 Jan 2020  Â·  5Comments  Â·  Source: reactiveui/refit

Is your feature request related to a problem? Please describe.
Per discussion on Twitter & Reddit recently, I believe we should switch the codebase from using space-based indentation to tab-based. This is to primarily benefit visually-impaired users reading and working with Refit's source code.

Describe the solution you'd like
Tabs used in source code instead of spaces, with a .editorconfig update to create a standard in the IDE that can be overridden by users.

Describe alternatives you've considered
N/A

Describe suggestions on how to achieve the feature
With each PR, ensure that modified files use tabs instead of spaces. Ideally fail the build if spaces are used (unsure how to enforce, maybe a Stylecop rule?), or possibly look at swapping spaces with tabs using a post-commit hook.

Additional context
https://twitter.com/BrentO/status/1148211390429184001
https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/

Edit: Somebody on the Reddit thread has linked to a post by Lea Verou, I'll quote part of it here, in order to clearly identify the underpinning logic as to why tabs make for more accessible source code:

The width of a tab character can be adjusted per editor. This is not a disadvantage of tabs as commonly evangelized, but a major advantage. People can view your code in the way they feel comfortable with, not in the way you prefer. Tabs decouple the code’s presentation from its logic, just like CSS decouples presentation from HTML. They give more power to the reader rather than letting the author control everything. Basically, using spaces is like saying “I don’t give a rat’s ass about how you feel more comfortable reading code. I will force you to use my preferences because it’s my code”.

outdated

Most helpful comment

"We have exactly zero people who actually have a disability ask for this."

I'd like to make an analogy here. Whilst we're a community effort, this is relevant.

Let's say that we run a high-street retail business.
Let's say that our premises have two steps up to entering the "shop floor" from the street.
The law both in the UK, EU & US requires us as a shop to have a ramp for disabled customers to be able to enter the store.
Is this an inconvenience for us? Yes.
Is it a reasonable adjustment, as defined by the laws codified (ADA, DDA & EDHR, US< UK & EU respective laws) in these jurisdictions? Yes.

We can change spaces to tabs easily for us, it's a relatively minor adjustment to allow us to include more people. We can do this with automated scripts, .editorconfig settings, and some Git hooks. This is low-effort inclusion.

If we don't offer a ramp, people won't feel welcome in our "shop".
We should, morally, offer the ramp. Even if only one or two people use it - our job is to be inclusive.

I am therefore reopening this issue on that basis.

All 5 comments

Currently, there is a known issue with Github displaying tabs as 8 spaces by default, and AFAIR there is no way to adjust this setting, except playing with URL query parameters manually. This can cause the codebase to be less readable than it is now:

public class Example {
    public int Row { get; }

    public Example(IDependency dependency) {
        using (var data = dependency.CreateScope())
        {
            data.Connect()
                .Transform(x => new Thing(x))
                .Subscribe(thing => Row = thing.Row);
        }
    }
}

The same snippet, but with tabs replaced with 4 spaces:

public class Example {
    public int Row { get; }

    public Example(IDependency dependency) {
        using (var data = dependency.CreateScope())
        {
            data.Connect()
                .Transform(x => new Thing(x))
                .Subscribe(thing => Row = thing.Row);
        }
    }
}

It would be great if they'd change the default setting back one day, earlier they used 4 spaces by default. Or, one can do this by using a custom plugin.

Nope, this will 100% fuck every outstanding PR and completely trash the blame, please do not do this. We have exactly zero people who actually have a disability ask for this.

"We have exactly zero people who actually have a disability ask for this."

I'd like to make an analogy here. Whilst we're a community effort, this is relevant.

Let's say that we run a high-street retail business.
Let's say that our premises have two steps up to entering the "shop floor" from the street.
The law both in the UK, EU & US requires us as a shop to have a ramp for disabled customers to be able to enter the store.
Is this an inconvenience for us? Yes.
Is it a reasonable adjustment, as defined by the laws codified (ADA, DDA & EDHR, US< UK & EU respective laws) in these jurisdictions? Yes.

We can change spaces to tabs easily for us, it's a relatively minor adjustment to allow us to include more people. We can do this with automated scripts, .editorconfig settings, and some Git hooks. This is low-effort inclusion.

If we don't offer a ramp, people won't feel welcome in our "shop".
We should, morally, offer the ramp. Even if only one or two people use it - our job is to be inclusive.

I am therefore reopening this issue on that basis.

Apologies to those who got email notifications with my previous rant (now deleted). From the context I thought this was about physical impairment, and I had failed to read the linked Reddit post that makes the case for it from a visual impairment standpoint.

I would still hope that the debate results in people using tools that assist them better, rather than making decisions that cause an access conflict.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ColKrumpler picture ColKrumpler  Â·  3Comments

tstivers1990 picture tstivers1990  Â·  5Comments

eduardocampano picture eduardocampano  Â·  6Comments

martincostello picture martincostello  Â·  4Comments

nvivo picture nvivo  Â·  6Comments