User configuration

[jh-orange]

While not denying consistency of format is an absolute necessity (at least for code touched by more than one person), having a standard, immutable, option should be sufficient to thus allow any individual to make adjustments suiting his sensibilities. All the next user has to do is right click and select reformat. The absolute ease to be able to "return to standard" obviates the need for the (clearly and admittedly) opinionated format being forced upon the world. Intelligent formatting applications have effectively ended the "brace wars." So why persist?

Given that this section states:

"Specifically: Respect people, their identities, their culture, and their work. Be kind. Be courteous. Be welcoming. Listen. Consider and acknowledge people’s points before responding"

then shouldn't that also apply to other's development choices?

[odogy]

I'd also like to pose the question of whether the current approach really is the most effective way to achieve the stated goal of community code consistency. It seems possible to me that by opening the doors just a little on a few high profile requests, such as [https://github.com/Dart-Code/Dart-Code/issues/914], we actually might keep Dart code more consistent. If the advice to anyone who has trouble working with 2 space indentation or spaces in place of tabs is to essentially disable Dart formatting altogether, then the result will be that the code those people produce will undoubtedly be further from the standard than necessary just to achieve those specific goals. In other words, the best way to achieve consistency may be to factor audience acceptance into the equation.

[jh-orange]

Totally missing the point that for one to reset the source to a common format takes one click.

On Sun, Jul 5, 2020, 2:21 PM odogy notifications@github.com wrote:

I'd also like to pose the question of whether the current approach really is the most effective way to achieve the stated goal of community code consistency. It seems possible to me that by opening the doors just a little on a few high profile requests, such as https://github.com/Dart-Code/Dart-Code/issues/914 http://url, we actually might keep Dart code more consistent. If the advice to anyone who has trouble working with 2 space indentation or spaces in place of tabs is to essentially disable Dart formatting altogether, then the result will be that the code those people produce will undoubtedly be further from the standard than necessary just to achieve those specific goals. In other words, the best way to achieve consistency may be to factor audience acceptance into the equation.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dart-lang/dart_style/issues/934#issuecomment-653940738, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATDXEOXTFA7D37S3QICNPDR2DVEXANCNFSM4ON5K7UQ .

[odogy]

Totally missing the point that for one to reset the source to a common format takes one click. …

I understood that you were giving one reason why allowing some customization would be okay. I gave an additional reason. I think if you reread my comment you'll see we're not at odds.

[jh-orange]

No, I fully understood your point. I just can't see any downside to allowing customization. Additionally, for the who believe that the 1TBS is counter-productive, writing code in one's own standard, regardless of how arguably misguided it may be, has to help productivity.

On Sun, Jul 5, 2020, 7:02 PM odogy notifications@github.com wrote:

Totally missing the point that for one to reset the source to a common format takes one click. … <#m2075330205665060416>

I understood that you were giving one reason why allowing some customization would be okay. I gave an additional reason. I think if you reread my comment you'll see we're not at odds.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dart-lang/dart_style/issues/934#issuecomment-653977597, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATDXELTWGK4V7QOCJAQBSLR2EWEDANCNFSM4ON5K7UQ .

[munificent]

I just can't see any downside to allowing customization.

The downsides that I see are documented here. An entire different category of downsides is cost. There is no magic button I can push that will implement every different way you might want the formatter to work and then produce a complete comprehensive, correct test suite to validate that the implementation works as intended.

For every customizable option supported, the set of combinations increases exponentially. If you want dartfmt to support two-space indentation, then at a minimum that requires deciding, implementing and testing the indentation rules for wrapped expressions, nested blocks, multi-line statements that lack braces, constructor initialization lists, cascades, etc. If you always want it to support different brace styles, now you need to test all combinations of brace style and indentation.

This cost is essentially invisible to dartfmt users because they don't have to implement it. But it is certainly not invisible to me or the Dart team. Time I spend working on that to please a small fraction of users is time I'm not spending improving dartfmt's performance, fixing bugs that affect all users, evolving "Effective Dart" to keep up with changing practices, designing new language features, etc.

It's hard for me to believe that adding support for two-space indentation to dartfmt is the most valuable thing I could spend my limited time on Earth doing for the Dart ecosystem.

writing code in one's own standard, regardless of how arguably misguided it may be, has to help productivity.

That "has" is an assertion, but do you have evidence to support it? In the absence of that evidence, what justification do I have to sink real engineering time into this?

[jh-orange]

Cost is acceptable, understandable, and cannot be argued. The other reasons are not.

Actually, I don't care much about the spacing issue, I can take or leave most of the other options. What I truly hate, and have for the past 30 years, is the totally illogical placement of braces (which is exacerbated by the two-space indentation because now it's harder to "see" the corresponding element. Past languages that used BEGIN/END blocks (Algol was my first) were smart enough to start them on new lines. Even the modest adamant non-Allman C coders broke their rules on functions and classes. THat inconsistency was insane.

Support the allegation? Just anecdotally, because I know how much time I spend searching for the matching brace (even with the editor support) - you have to move your head/eyes up and to the left. WIth dart it's even worse, because of all the parentheses that are used in basically the same manner. As an aside, my first programming language was Lisp (lots ao parens!), then for years assembly language (even when I started at IBM, where, among other things, I have written compilers - sort of the reverse of the formatting issue but the same techniques can be used for the formatting issue). I've been doing this a while.

One last question: I'm using Android Studio. How do I turn off dartfmt? I'll gladly turn it back on when I'm done with a module.

Thanks for your patience. Word of advice though. In the future, give the real reason. It's impossible to reliably give an artificial reason for something that will withstand scrutiny.

Is there any way to specify an optional formatter? I'd be willing to make the effort although I can't guarantee I have any amount of free time to commit to such an undertaking.

John Hennessy

On Fri, Jul 10, 2020 at 3:03 PM Bob Nystrom notifications@github.com wrote:

I just can't see any downside to allowing customization.

The downsides that I see are documented here https://github.com/dart-lang/dart_style/wiki/FAQ#why-cant-i-configure-it. An entire different category of downsides is cost. There is no magic button I can push that will implement every different way you might want the formatter to work and then produce a complete comprehensive, correct test suite to validate that the implementation works as intended.

For every customizable option supported, the set of combinations increases exponentially. If you want dartfmt to support two-space indentation, then at a minimum that requires deciding, implementing and testing the indentation rules for wrapped expressions, nested blocks, multi-line statements that lack braces, constructor initialization lists, cascades, etc. If you always want it to support different brace styles, now you need to test all combinations of brace style and indentation.

This cost is essentially invisible to dartfmt users because they don't have to implement it. But it is certainly not invisible to me or the Dart team. Time I spend working on that to please a small fraction of users is time I'm not spending improving dartfmt's performance, fixing bugs that affect all users, evolving "Effective Dart" to keep up with changing practices, designing new language features, etc.

It's hard for me to believe that adding support for two-space indentation to dartfmt is the most valuable thing I could spend my limited time on Earth doing for the Dart ecosystem.

writing code in one's own standard, regardless of how arguably misguided it may be, has to help productivity.

That "has" is an assertion, but do you have evidence to support it? In the absence of that evidence, what justification do I have to sink real engineering time into this?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dart-lang/dart_style/issues/934#issuecomment-656912102, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATDXEKYUZP7UYVUCK2N7D3R26F2JANCNFSM4ON5K7UQ .

[ansorre]

@munificent

1) "... to please a small fraction of users...". Do you have any evidence to support the fact that it is a small fraction of people who wants to customize the formatter? How many people are using Dart? How many stop even trying to use it as soon as they discover that in order to write Dart code you are forced to comply to a set of prefixed forced formatting rules reminiscent of the stiffness of COBOL from decades ago that we all dreamed were now just a nightmare from the past? For sure I'm one of those who consider it a showstopper in the adoption of Dart.

2) Some decisions are simply wrong, no matter what point of view you try to evaluate them. Forcing a language formatter to be fixed is surely one of this. Not because I say it, but because of common sense. First: you say that it would be a waste of time to work on a customizable formatter, but then why work on a compiler that allows different placement/size of spaces, tabs, brackets? A compiler which expects all those things in prefixed position/spaces would be developed in way less time, so why you wasted time to allow different formats at compile time when they are never allowed to be used? Well, now this is not a good use of developer time and resources. Second: I've read that originally this decision was taken so that it would avoid infinite debating on formatting details for every project. Considering how many threads of gripes are flourishing about this decision I would simply acknowledge that the experiment failed, the solution imagined to solve a small problem created a much larger one. Experimenting is typical of intelligent people, persisting with a failed experiment is not.

3) People are not complaining that no one is working at the formatter in order to render it customizable. People are complaining that it is forbidden to have a customizable formatter for Dart language. Dart is all open source, no one can ever force you or anyone to work on this or that, and no one usually does this. What people cannot stand is that someone has decided that a fixed formatter ( https://github.com/dart-lang/dart_style/wiki/FAQ ) "End debates about style issues in code reviews" (false, what are we doing here and in countless threads?), "Produce beautiful, readable output that helps users understand the code", who decided that? For vast majority of people no matter what rules, if those are not their own rules with which they are probably used to work since decades, your set of rules accomplishes exactly the opposite effect:
"Produce horrible, un-readable output that greatly hampers users in understanding the code". Now a day we are all used since many years to work with IDEs that allow us to get the code, reformat those sources we want to work on the way we like and then reformat them back the way the project wants before pushing our changes. Why Dart should be against this very well, modern, liberal, consolidated, proved to be very effective way of working with a programming language? Not to mention that this gives competitors an incredible advantage over Dart. Look to those IDEs who are very happy to comply with these Dart restrictions, so that other competing languages who don't have them get more preferred by programmers...

I can't wait for this decision to be reverted and for programmers to be set free to choose their own code styles and directly work at the formatter as is the case with any good open source project. I really like Dart and would start using it right away. But until that happens, sorry I'm not ready to go back decades to the days of COBOL.

Thanks for reading.

[munificent]

"... to please a small fraction of users...". Do you have any evidence to support the fact that it is a small fraction of people who wants to customize the formatter?

Yes. Use of dartfmt is mandatory for all Dart code inside of Google. I don't think I can publicly say the number of users, but it is large. I get consistent feedback from many of them that the lack of configuration is a positive feature and I rarely get any feedback that they want it to be configurable.

in order to write Dart code you are forced to comply to a set of prefixed forced formatting rules reminiscent of the stiffness of COBOL

You are absolutely not required to use dartfmt in order to write Dart code. It is a completely optional tool and all of our compilers, runtimes, and static analyzers are perfectly happy to consume Dart code regardless of how it is formatted.

First: you say that it would be a waste of time to work on a customizable formatter, but then why work on a compiler that allows different placement/size of spaces, tabs, brackets?

This is a great question.

In this case, it turns out writing a compiler that ignores all whitespace is actually simpler than one that requires specific formatting. The compiler is more permissive, which means it has to implement fewer explicit checks when parsing code. This might be less true if Dart treated whitespace as significant, but it does not. The way the language is currently designed, bracketing characters and semicolons alone are sufficient to parse the code unambiguously, so forcing the compilers to also look at whitespace would add, not remove complexity.

People are not complaining that no one is working at the formatter in order to render it customizable. People are complaining that it is forbidden to have a customizable formatter for Dart language.

You are not forbidden. Not only is anyone welcome to write a Dart formatter, you are even welcome to fork dartfmt itself and use it as a starting point, which is surely a very large effort saving on the part of anyone wanting to write a formatter.

[pjdupreez]

I just want my 'else' statements on new lines... is that too much to ask? Just to clarify, collapsing code like this is annoying:

if (foo) {...} else if (bar) {...} else {...}

Also,

"You are absolutely not required to use dartfmt in order to write Dart code. It is a completely optional tool and all of our compilers, runtimes, and static analyzers are perfectly happy to consume Dart code regardless of how it is formatted."

Yet I cannot seem to find alternatives for Android Studio...

[munificent]

I just want my 'else' statements on new lines... is that too much to ask? Just to clarify, collapsing code like this is annoying:

if (foo) {...} else if (bar) {...} else {...}

The formatter will not collapse code like that, unless those blocks are completely empty, which is very unusual. If you have deliberately empty blocks, then an easy fix that also helps people understand the code is to leave a line comment inside the block explaining why it's empty.

[pjdupreez]

Thanks for the reply, but the code blocks are not empty... in fact, the are the else if code blocks containing logic for flutter_bloc states, ie if (state is foo) {do some stuff} else if... you get the picture. But its fine as I moved over to VS Code... no problem there

On Wed, 16 Dec 2020, 03:18 Bob Nystrom, notifications@github.com wrote:

I just want my 'else' statements on new lines... is that too much to ask? Just to clarify, collapsing code like this is annoying:

if (foo) {...} else if (bar) {...} else {...}

The formatter will not collapse code like that, unless those blocks are completely empty, which is very unusual. If you have deliberately empty blocks, then an easy fix that also helps people understand the code is to leave a line comment inside the block explaining why it's empty.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dart-lang/dart_style/issues/934#issuecomment-745700339, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH4NCDUOURKEJYU5MNW4O3SVADFRANCNFSM4ON5K7UQ .

[munificent]

Thanks for the reply, but the code blocks are not empty... in fact, the are the else if code blocks containing logic for flutter_bloc states, ie if (state is foo) {do some stuff} else if... you get the picture.

Can you show me the actual code you are formatting? The formatter should never collapse a non-empty block.

[pjdupreez]

Please see the screenshots attached. First two are from Android Studio, the other 2 from VS Code. Android Studio is where it collapses all wrong.

I am working on Ubuntu 20.04.1 LTS [image: android_studio.png] [image: android_studio_2.png] [image: vscode.png] [image: vscode_2.png]

Like I said, the else if blocks are not empty. Very odd behaviour...

Regards,

On Wed, 6 Jan 2021 at 01:21, Bob Nystrom notifications@github.com wrote:

Thanks for the reply, but the code blocks are not empty... in fact, the are the else if code blocks containing logic for flutter_bloc states, ie if (state is foo) {do some stuff} else if... you get the picture.

Can you show me the actual code you are formatting? The formatter should never collapse a non-empty block.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dart-lang/dart_style/issues/934#issuecomment-754960618, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH4NCDPFOXGWZU5SJ43J3TSYONG7ANCNFSM4ON5K7UQ .

[munificent]

That looks like it may be coming from the way Android Studio chooses to render those collapsed {...} blocks. The underlying file itself (which is all dartfmt ever touches) should have the newlines there.