Accessibility problem: indent forces 2 spaces instead of 4

[tgrushka]

I am a legally blind Dart developer. I didn't seem to have this problem before. Suddenly, in VS Code and when running dart format, it seems that it is forcing indentation at 2 spaces instead of 4. This makes it harder for me to see the indentations. There is an --indent flag but that only affects leading indentation, which doesn't make sense to me. Please fix this. Thank you.

[munificent]

Hi, Tom. Thank you for reaching out.

I didn't seem to have this problem before. Suddenly, in VS Code and when running dart format, it seems that it is forcing indentation at 2 spaces instead of 4.

The dart format command (and this package, which implements it) has always used 2 spaces of indentation for block-level indentation. It's been this way for over a decade with no way to configure it to anything else.

It may be that you were using VS Code without the Dart plug-in installed and you were getting VS Code's built-in simpler formatting logic instead of dart format? I'm not sure, but I am sure that this formatter has never done +4.

There is an --indent flag but that only affects leading indentation, which doesn't make sense to me.

That flag exists primarily for integrations into other editors where the plug-in wants to format just a selection region of code and wants to preserve the surrounding integration. It's honestly... probably not very useful. That flag has been there forever and I don't know how often it's used.

The formatter has always been non-configurable by design. This makes it a good tool for getting the entire Dart ecosystem to have a consistent style (which I believe helps overall readability). But it makes it not a great tool for users who want a formatter that fits their specific accessibility needs or other personal preferences.

I consider readability and accessibility more or less the same thing—"readability" is just what we call accessibility for people whose vision is closer to normal. As far as I've been able to tell, the current indentation style doesn't seem to cause accessibility issues for most vision-impaired users. Google has long cared about accessibility and the company's official coding styles for C++, C#, HTML, CSS, JavaScript, Java, Objective-C, and Swift all mandate +2 indentation. (The outliers are Go whose gofmt uses tabs for indentation and Python, which follows PEP 8's recommendation of +4 spaces.) That led me to conclude that at least for most vision-impaired programmers, 2 spaces of indentation is acceptable.

(One nice thing about 2 spaces of indentation and Dart's 80-column page width is that it generally makes lines of code narrower which can in turn allow users to use a larger font size. I'm not vision-impaired myself beyond needing glasses, but I am getting older, and every half-decade or so I seem to increase my code font by a point size.)

You probably know about this already, but many editors let you visually emphasize the indentation nesting. Using VS code, mine looks like:

Personally I find that helps me read the indentation more effectively than more spaces of nesting does. Obviously, I understand that my experience may not match yours since I have normal vision when wearing corrective lenses.

The main challenge with supporting different indentation depths for different users (aside from it leading to less consistency across codebases) is that indentation depth interacts with line wrapping and other alignment formatting. It's easy to nicely format using +4 indentation in code like this:

main() {
    if (condition) {
        print('Hello, world!');
    }
}

But it's less clear in code like:

class SomeClass {
    SomeClass({
        SomeOtherLongType longParameterName,
        AnotherType anotherLongParameter,
    }) : _firstField = longParameterName +
            someOtherConstant,
        _secondField = anotherLongParameter -
            someConstant {
        if (someVeryLongCondition ||
            anotherLongCondition ||
            someOtherLongCondition) {
            theBodyIsHere();
            moreCodeInTheBody();
        }
    }
}

How much indentation should we do on the someOtherConstant,, _secondField, anotherLongCondition, and theBodyIsHere(); lines?

I'm sure someone could design a good style that answers those in a way that leads to overall readable code, but that work would have to be done holistically and the Dart grammar is huge. If you just do the basic thing of changing all block indentation to +4, the result is a style that I think is overall less readable and accessible for all users. (In particular, notice how hard is to tell where the if condition ends and the body begins here.)

My philosophy with the formatter is that the best way to maximize readability and accessibility for all users is to try to design one holistic style that covers everything and invest a lot of time into tuning it carefully in all the ways it can be composed. I think that works better than giving users a bunch of knobs they can turn but where many of the combinations compose in hard to read ways in various corners of the language.

(The other obvious advantage of having a single non-configurable style is that it's much less engineering effort. The formatter has thousands and thousands of tests just to cover a single style. Supporting configuration would increase that combinatorially.)

I feel really bad to essentially be saying "no", because accessibility is very close to my heart. But ultimately this is an engineering project with finite resources and I think the best way to use those resources is to try to make the formatter do one thing as well as I'm able to make it.