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.

[pewinski]

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.

[pewinski]

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.