Allow indent options to be configured

[DanTup]

It seems strange that line length can be configured, yet tab size cannot.

I'm probably not the only person that hates 2-space indenting; it would be rather nice if people can have their own preferences. I think it'd be nice to allow the user to set tab or x spaces, but even just being able to configure the number of spaces would be nice. Two spaces get lost too easily, especially when things like else and finally are already two characters in (after }).

[DanTup]

Re-reading the style guide, I guess this difference is significant :-(

AVOID lines longer than 80 characters.

DON’T use tabs.

(;ﾟ︵ﾟ;)

[joseluis]

Tabs vs spaces is a very opinionated subject with no clear winner.

I feel they have chosen to go with the lowest common denominator in order to achieve whitespace homogeneity avoiding most of the trouble. That makes sense, although I would have preferred that it would've been a suggestion, not an obligation. It's a shame, because for me nothing ever comes close to using smart tabs for code indentation.

[DanTup]

I don't want to turn this into a debate, but I think there is a clear winner... Tabs for indenting give people options, spaces do not. There is no good argument for using spaces ("I want to control how my code looks in your screen" is not a good argument). Spaces are only useful for alignment but since dartfmt throws all alignment away I think that's totally moot for Dart anyway! IMO, there was no good reason for spaces, but that ship has sailed!

In any case, the Dart style guide is pretty clear that you DON'T use tabs rather than just avoid them; so I don't think will happen :(

[munificent]

Sorry, but configurability is a non-goal:

https://github.com/dart-lang/dart_style/wiki/FAQ#why-cant-i-configure-it

I'm even hesitant to expose the line-length setting. It's mainly there for historical reasons and because it makes it easier to write small-scale tests. Real-world users should always leave it at the default 80.

[DanTup]

Sorry, but configurability is a non-goal

How about changing from spaces to tabs? Everyone is happy then! ;P

[gluons]

Come from Dart-Code/Dart-Code#1015 and Dart-Code/Dart-Code#914.

We need tab indent. 🙁

Reopen please.

[phanirithvij]

@munificent do you mind looking at this?

[munificent]

Sorry, but this is a non-goal for dartfmt. See here.

[Melmoth-the-Wanderer]

you get more code to reuse, more consistent code, it's easier to read and contribute to each other's code, etc. But it does that at the expense of individual preference.

Like... seriously? How come not having tab-size setting would introduce bad practices and prevent users from reusing their code? Isn't it IDE/screen size you're using that should dictate how to format the code for devs convenience?

That transitively improves the live's of each Dart developer as well

I have to disagree on this. Some developers are not JUST dart developers, and if someone is used to 4 spaces tab size it is painful to work with dart files with 2 spaces tab size. It makes no sense to me.
How about low vision people?

Lots of questions here. Please refer to any evidences (actual evidences, measurements. Not somebody's opinion) that having configurable task size makes developer life harder. I disagree and would like to be convinced that I'm wrong.

PS. Not to mention that you have to spend time searching for bugs in vscode plugin, googling thought different topic to realize that "this is not a bug, it's a feature". How convenient is this?

[munificent]

prevent users from reusing their code?

Because, like you say, "if someone is used to 4 spaces tab size it is painful to work with dart files with 2 spaces tab size".

If users configure their Dart formatting differently, then it is painful to work with each other's code. They are, of course, free to make that choice, but it's not of a goal of this tool to encourage that.

[Melmoth-the-Wanderer]

Because, like you say, "if someone is used to 4 spaces tab size it is painful to work with dart files with 2 spaces tab size".

There is (in most cases) a shortcut in your IDE to format code. If developer (for some wild reasons) need to copy and paste large amount of someone else's code (which shouldn't even happen on daily basis) he can simply re-format this code the way he likes in no time. And we're still talking about spacing here, it's not event single-vs-double-quote problem (which might be only sightly harder to adjust, though).

I do like to discuss "which approach is better and why", I do like to learn other person opinion on this. Although usually it is just a matter of preference and in such cases I do not appreciate imperative approach forcing anyone to do something in certain way.

Correct me if I'm wrong, but this will also require IDE maintainer to find a way to handle such edge cases when developer is not allowed to change formatting of dart files. Currently VSCode says: "yes, you can change it" but it simply has no effect. Not even a warning.

I believe the intentions behind the decision to restrict formatting are good but this is definitely setting new trends here and that's why I asked for some evidences behind the idea.

They are, of course, free to make that choice, but it's not of a goal of this tool to encourage that.

The goal of every open-source project should be (among others) to take feedback into consideration. However, I can't ask you to do so. If you're standing strong with your belief - I know how you feel. And I keep my fingers crossed for it.

[munificent]

Currently VSCode says: "yes, you can change it" but it simply has no effect.

That's unfortunate, but there's only so much we can do.

this is definitely setting new trends here

Gofmt is also deliberately non-configurable.

The goal of every open-source project should be (among others) to take feedback into consideration.

Yes. I have gotten a lot of feedback over the years that most users prefer the lack of configurability. Or, more concretely, they prefer:

• Having a single canonical style and not having to have arguments about which configurations to choose.
• Having a familiar style when they look at other people's code.
• Being able to apply automated refactoring to large bodies of code without having to worry about different styles in different portions of it.
• Having more dartfmt features because of the freed up resources not spent implementing configurability and a range of different formatting styles.

[Melmoth-the-Wanderer]

Thank you for explaining the reasoning behind.

[ghost]

Four spaces in the indentation, please. It is very bad two spaces, it goes against the preference of most developers. It's been a turning point for me to refuse to continue with the Dart language. 🙁

[phanirithvij]

@munificent vscode and other editors have configuring spaces or tabs and spaces width and tab width. You are too stubborn to not provide the features for more than 50% of the developers who would take it for granted that 4 spaces indentation is the default.

There is no advantages if you force indentation to be 2 spaces. And there are no disadvantages if you make 4 spaces available. Your reasoning is not meaningful.

Having a single canonical style and not having to have arguments about which configurations to choose.

No one's going to come flood you with which configuration to choose if you provide multiple configurations, because there would be a stackoverflow answer or a blog post which will clarify about that. Or they would continue coding on the style they're used to.

[safield]

+1 to please reconsider please. Two space tabs can be very hard to read and distinguish for people with certain vision issues. This accessibility issue (albeit not intentionally or knowingly) is hampering inclusivity for the language.

I think this change could make a lot of people happy, and not severely impact the design goals of this project.

Thanks.

[theniceboy]

I have to say that I prefer tabs over spaces by a TIIIIIINNNY BIT (just like Richard from Silicon Valley lol) but having this particular indent option nonconfigurable is really a bummer. I read the reasoning behind the indent space decisions and I think they are valid, but please consider adding the option to use tabs over spaces! Other than that, great job, dartfmt is absolutely great!

[LittleCornerDev]

I very strongly prefer tabs over spaces because everyone can use the tab width they prefer for readability while still maintaining the same indentation integrity and everyone is happy. It's much clearer to see exact indentation level with tabs (when whitespace characters are set to visible) and easier to delete an indentation level (with a single backspace/delete and no special keys added).

I just started learning Dart/Flutter and was setting it up on Android Studio, but tabs instead of spaces is always the first format preference I set up and discovering this major limitation is why I am switching to VS Code as it seems other frustrated developers are doing.

[brettp]

+1 to this being a significant accessibility issue, partly because of the required 2-space indent, and request serious reconsideration of the current approach.

An auto formatter is necessarily bidirectional: it converts code you can read (and may have written) into code I can read, and it also converts code I can read (and may have written) into code you can read. I would argue that portable readability -- NOT enforced uniformity -- is the main purpose of an auto formatter.

dartfmt insists on a unidirectional conversion of code I can read into code someone else can read. While writing code, my primary concern is that I can read it. With standard auto formatters, I can offload the concern of ensuring others can read it to my dev toolchain.

I understand dartfmt is not technically a required part of the toolchain (for the public), but its deep integration with the rest of the SDK (and no viable alternative) makes its use a de facto requirement. This type of approach will indeed make all the code look the same but at the expense of accessibility to those of us who require the code to not look the same.

[munificent]

I would argue that portable readability -- NOT enforced uniformity -- is the main purpose of an auto formatter.

I certainly support people making formatters with that charter, but it's not the charter of dartfmt. My personal goals with dartfmt are to make the Dart ecosystem as a whole easier for users to read, learn from, and contribute to. I want Dart's community to be open and approachable and having code that doesn't frequently alienate people because each package is formatted to its own preferred artisanal style is a big part of that. I used to be a C++ developer and code reuse is significantly hampered in C++ in part because every C++ codebase is its own little world.

Further, Google's goals with dartfmt are to have a consistent internal corpus of Dart code to enable people to move across teams easily, perform large-scale refactorings across Google's codebase (which we do frequently), and to make code reviews as efficient and pleasant as possible.

A consistent, unconfigurable style is exactly inline with why I want to work on dartfmt and why Google pays me to. You can argue that those aren't your goals, and that's totally OK. I support people having different preferences in their tools. In fact, I support that so strongly that dartfmt is itself open source and I've gone out of my way to document it, explain how it works, and write copious tests, all to make it easier to fork and build on all of the work I've poured into it.

This type of approach will indeed make all the code look the same but at the expense of accessibility to those of us who require the code to not look the same.

I am very sensitive to this issue, but I have yet to see evidence that the current indentation rules have accessibility problems. Google's style guides for C++, Java, and JavaScript all mandate 2 spaces of indentation. There are billions of lines of code inside Google formatted that way, and many Googlers with a wide variety of vision impairments that Google has a vested interest in keeping productive.

[brettp]

@munificent - Thanks for the reply.

My personal goals with dartfmt are to make the Dart ecosystem as a whole easier for users to read, learn from, and contribute to.

I feel it's necessary to mention that when you say "users" here, it means "users who expect to see code how I expect to see code." There are, at very minimum, at least the participants in this thread who disagree that the current restriction improves readability.

A consistent, unconfigurable style is exactly inline with why I want to work on dartfmt and why Google pays me to. You can argue that those aren't your goals, and that's totally OK. I support people having different preferences in their tools.

I'm not following this logic. You state that your goal is to make sure all code style is identical so the ecosystem will benefit, but then say that folks are free to use their own (or no) formatter. Doesn't that just cause the same, if not worse, style fragmentation? Wouldn't it make more sense to have the de facto formatting standard be more compatible with these user preferences than to suggest to use a different or forked tool? See also my original argument that auto-formatters are be bi-directional as a resolution for this style fragmentation.

but I have yet to see evidence that the current indentation rules have accessibility problems

This feels like a disingenuous statement because you are disclaiming evidence within a thread where multiple people cite evidence. Quick searches also pull up many discussions about frustrated VS Code users (at least). c.f. threads like this. It is manifests in features present in some Dart IDE plugins, like closing label annotations, that are meant to make indent levels more readable since the formatter cannot.

Additionally, you may not hear anything because people who have a choice stop using dartfmt, and people who don't (like Google) are referred to threads saying it's by design.

In the spirit of open source, if I submit a merge request to allow customization of indent character and tab size, would it be considered?

[ghost]

"I am very sensitive to this issue, but I have yet to see evidence that the current indentation rules have accessibility problems. "

I developed dart projects, and I am determined to never develop anything with this language again because of this crazy indentation. Good luck to the genius who invented this rule, won my eternal dislike.

[munificent]

I feel it's necessary to mention that when you say "users" here, it means "users who expect to see code how I expect to see code."

For what it's worth, I don't personally like all of dartfmt's formatting choices either. I implemented the rules it uses based on what was most prevalent in the ecosystem, even when that goes against my own preferences. In fact, I've spent most of my career using +4 indentation, though I'm used to +2 now.

There are, at very minimum, at least the participants in this thread who disagree that the current restriction improves readability.

There are people in this thread who dislike the formatter's output, which I respect. But I haven't actually seen evidence that it impacts their ability to read the code.

You state that your goal is to make sure all code style is identical so the ecosystem will benefit, but then say that folks are free to use their own (or no) formatter. Doesn't that just cause the same, if not worse, style fragmentation?

Yes, I would be sad if Dart users did start using wildly different formatters because I think it would harm the ecosystem for relatively little benefit. But I support their right to do that.

Additionally, you may not hear anything because people who have a choice stop using dartfmt, and people who don't (like Google) are referred to threads saying it's by design.

This is why I mentioned the other language style guides within Google. This isn't just about Dart users. There are many more Googlers programming in C++, Java, and JavaScript also using +2 indentation. Google has a pretty strong culture of caring about accessibility internally. I believe that if indentation was an accessibility issue that Google wouldn't have those styles.

[jepperaskdk]

I feel it's necessary to mention that when you say "users" here, it means "users who expect to see code how I expect to see code."

For what it's worth, I don't personally like all of dartfmt's formatting choices either. I implemented the rules it uses based on what was most prevalent in the ecosystem, even when that goes against my own preferences. In fact, I've spent most of my career using +4 indentation, though I'm used to +2 now.

There are, at very minimum, at least the participants in this thread who disagree that the current restriction improves readability.

There are people in this thread who dislike the formatter's output, which I respect. But I haven't actually seen evidence that it impacts their ability to read the code.

You state that your goal is to make sure all code style is identical so the ecosystem will benefit, but then say that folks are free to use their own (or no) formatter. Doesn't that just cause the same, if not worse, style fragmentation?

Yes, I would be sad if Dart users did start using wildly different formatters because I think it would harm the ecosystem for relatively little benefit. But I support their right to do that.

Additionally, you may not hear anything because people who have a choice stop using dartfmt, and people who don't (like Google) are referred to threads saying it's by design.

This is why I mentioned the other language style guides within Google. This isn't just about Dart users. There are many more Googlers programming in C++, Java, and JavaScript also using +2 indentation. Google has a pretty strong culture of caring about accessibility internally. I believe that if indentation was an accessibility issue that Google wouldn't have those styles.

Take a look at the dislikes you're receiving. Your arguments are weak, religious and makes it seem like this is a primarily a google-tool, and not for everyone. Definitely gonna look for alternatives.

[ghost]

I feel it's necessary to mention that when you say "users" here, it means "users who expect to see code how I expect to see code."

For what it's worth, I don't personally like all of dartfmt's formatting choices either. I implemented the rules it uses based on what was most prevalent in the ecosystem, even when that goes against my own preferences. In fact, I've spent most of my career using +4 indentation, though I'm used to +2 now.

There are, at very minimum, at least the participants in this thread who disagree that the current restriction improves readability.

There are people in this thread who dislike the formatter's output, which I respect. But I haven't actually seen evidence that it impacts their ability to read the code.

You state that your goal is to make sure all code style is identical so the ecosystem will benefit, but then say that folks are free to use their own (or no) formatter. Doesn't that just cause the same, if not worse, style fragmentation?

Yes, I would be sad if Dart users did start using wildly different formatters because I think it would harm the ecosystem for relatively little benefit. But I support their right to do that.

Additionally, you may not hear anything because people who have a choice stop using dartfmt, and people who don't (like Google) are referred to threads saying it's by design.

This is why I mentioned the other language style guides within Google. This isn't just about Dart users. There are many more Googlers programming in C++, Java, and JavaScript also using +2 indentation. Google has a pretty strong culture of caring about accessibility internally. I believe that if indentation was an accessibility issue that Google wouldn't have those styles.

Take a look at the dislikes you're receiving. Your arguments are weak, religious and makes it seem like this is a primarily a google-tool, and not for everyone. Definitely gonna look for alternatives.

@jepperaskdk, I totally agree with your point of view.

[phanirithvij]

Sorry, but configurability is a non-goal

Should be Sorry, but readability is a non-goal
Because 2 spaces makes me feel claustrophobic.

And asking the community to fork and maintain separately just for this? Wow

[vrnvorona]

Rephrasing my disruptive comment: there is no way customisation is worse than lack of it. People are different. So should their settings be.

[munificent]

Since I've been compared to the dictator of North Korea, I think that's a good cue that it's time to lock this issue.