deno fmt accessibility

[brandonkal]

I really like the idea of "one formatting style". People spend too much time on these matters. I also currently use two spaces for JavaScript files as it is the Prettier default.

But thinking more about the accessibility issues with defaulting to a small indent size, deno should reconsider.

Ref: https://github.com/stylelint/stylelint/issues/4246
https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/

It is hard to read code when it is scrunched to one side. We have less of a need for a small indent size given the move from callbacks to async/await.

Given the above, I'd like to see deno fmt consider defaulting to use tabs before 1.0. When editing a file with tabs, the user can choose whether an indent should visually be displayed as 2, 4, or even 8 spaces. Tabs would also be more consistent with go fmt which the tool is clearly inspired from. I'm not interested in starting a holy war on this though.

I'd also like to see the ability to set the deno fmt CLI arguments as environment variables so users could use deno fmt if they strongly disagree with the defaults.

[kitsonk]

Since deno fmt is configurable, I say we stick with our defaults.

[brandonkal]

But do consider that two spaces is unreadable for many people (this even varies between codebases). The article changed my mind on that. There is a reason TypeScript emits four spaces. Indentation is important. But using spaces forces the visual preference on everyone. For instance, you are fine seeing indents as two characters. My visually impaired friend needs 4 to be productive. By using the indentation character Tab, both of you can be happy. You can even ignore the key itself and your IDE will handle things for you.

Still, I can understand your fear to rock the boat...

For that, see my second suggestion. Allow us to set a

DENO_FMT_ARGS="--use-tabs --arrow-parens=always"

environment variable. That makes things close-to-seamless for codebases that care to be accessible.

[David-Else]

Deno formatting defaults should stick to what Prettier decides, that is the point of Prettier, so everyone can have the same formatting. With 80 characters print width any more than 2 spaces messes things up. It is all a fine balancing act. 80 chars and 2 spaces indent works great on a 1080p screen so you can get 2 columns.

The only exception to using the Prettier's current defaults is of course... it should be single quotes by default! I assume people touch type, the single quote are so much better. I understand that the Prettier team are considering switching to this in the future, so maybe it would be sense to beat them to it :)

Prettier 2.0 (old)
Summary:

Things that appear to have consensus:

4102: Change the default value for singleQuote to true

https://github.com/prettier/prettier/issues/3503#issuecomment-359863688

It does not really matter though, as there is a command line option to use single quotes in deno, but I just thought I would nerd out and mention it here :)

I have never heard of the 2 spaces being an accessibility issue before, so I don't think this is a mainstream opinion. I do applaud people thinking about accessibility issues though, it is important.

[brandonkal]

@David-Else 😆 I very much like single quotes as well! The thing is it doesn't really matter there. Touch type with single quotes and prettier will save it as double. I don't have a strong opinion on tabs vs spaces. But it is more accessible.

If you have to use a very large font, you may set tabs to use one column. If you have a 1080p screen and the code isn't terribly complex, you'll set it to two. If there is a lot of branching or you have a 4K screen, you'll set it to four or even 8. This can all be done without changing the file contents which is a distinct advantage. As far as I can tell, prettier treats tabs as 2 columns when printing.

I also believe it depends on what you are doing. For front-end (where more information is conveyed by JSX brackets etc) I've never had an issue with 2 column indents and 80 columns. Now as I write a Kubernetes client with all of that complexity, increasing the visible indent makes it easier to follow the complex TS types and branching.

Still, it is worth looking at before Deno 1.0.

[ry]

2 space indent and 80 columns is what we're sticking with.

[Alhadis]

JSYK, I once gave myself legitimate eye-strain trying to follow 2-space indented code for a pull-request. I actually gave up, and have been contributing less to open source projects because of the prevalence of this horrible tab-stop width.

Not saying "please change the defaults", I'm only lending credence to what @brandonkal's been saying about accessibility. It's a very real issue.

*drops mic*

2 space indent and 80 columns is what we're sticking with.

Not when I read it. 😁