Against rigid code formatters in general and Dart’s in particular

62 views
Skip to first unread message

Guyren Howe

unread,
Jun 12, 2021, 4:27:16 AM6/12/21
to Dart Misc
The list of hard things in programming includes reading and following the code you have to interact with. So, I think that the readability of code is actually of great importance. 

I find that I can read anyone’s thoughtfully formatted code just fine. So I don’t think there’s a strong general case for a rigid code formatter.

The BIG problem with Dart here is that not only are we being strongly encouraged to use the rigid default code formatter universally, but that the rigid default code formatter is AWFUL.

The RDCF produces wide walls of logical elements, multiple semantic elements on a line, no alignment, not really anything readable at all.

PLEASE maybe fix the default and make it good?

OR make the formatter configurable?

OR stop pushing everyone to use the awful formatting.


And for developers: reject the code formatting hegemony! Format free!

Bob Nystrom

unread,
Jun 14, 2021, 1:34:50 PM6/14/21
to General Dart Discussion
On Sat, Jun 12, 2021 at 1:27 AM Guyren Howe <guy...@gmail.com> wrote:
The list of hard things in programming includes reading and following the code you have to interact with. So, I think that the readability of code is actually of great importance. 

I find that I can read anyone’s thoughtfully formatted code just fine. So I don’t think there’s a strong general case for a rigid code formatter.

The BIG problem with Dart here is that not only are we being strongly encouraged to use the rigid default code formatter universally,

We ship dartfmt with the SDK, but it's entirely up to you whether you use it or not. The only real encouragement that we (the Dart team) give is that using dartfmt will slightly affect your package's automated scoring if you publish it on pub. There is an open issue discussing it here.

I'd gently suggest that much of this encouragement is actually coming from the Dart ecosystem itself and if many others writing Dart want everyone to use the same formatter, that might be saying something.

but that the rigid default code formatter is AWFUL.

We don't track CSAT for dartfmt separately (now that you mention it, it would be nice to have that data). But we track CSAT of the Dart SDK as a whole and users frequently mention dartfmt specifically as something they really like about the Dart toolset.

 no alignment,

I like how alignment looks too, but it makes diffs unnecessarily noisy. Make one element in a large aligned list longer, and all of the other lines have to be adjusted too, leading to giant whitespace-only diff lines. That in turn makes code review more difficult, and easing code review is a primary goal of dartfmt. Because of that, we decided to generally avoid aligning elements across lines.

Also, it's technically difficult to implement well.

PLEASE maybe fix the default and make it good?

I'm always interested in formatting changes that produce better output in the eyes of most users for most code. That's why we recently put in place a change process for the style. If you have concrete suggestions (by "concrete" I mean "described precisely enough that you could imagine how an automated formatter would implement it"), please don't hesitate to file issues.

However, I certainly can't promise we'll make any particular changes. You may find that what you consider to be clearly better is less so to a majority of others.
 
OR make the formatter configurable?

It's reasonable to want a configurable formatter, but that's not the charter of this formatter: https://github.com/dart-lang/dart_style/wiki/FAQ#why-cant-i-configure-it

OR stop pushing everyone to use the awful formatting.

I'd also like to point out that I am an actual human who spent a year of my life implementing the fastest, most readable automated style I could come up with while trying to satisfying clashing strongly held stylistic preferences among thousands of Dart users. It's OK if you don't like the results, but not publicly referring to it as "AWFUL" and a "hegemony" would be kind.

Also, as an exercise, you might try forking dart_style and implementing some of the styles you prefer. You may find that it's harder than it seems to translate your preferred hand-authored style to something that can be mechanically applied to all of the world's Dart code. Many styles look nice for code deliberately tailored to it but get egregiously bad when applied to other unexpected code. Dartfmt doesn't have the luxury of only accepting code it likes. :)

– bob

Michael Thomsen

unread,
Jun 15, 2021, 5:01:41 AM6/15/21
to mi...@dartlang.org
Hi Guyren,

Can you say a little about how you feel "pushed" towards using the formatter? As Bob mentioned, while it's certainly recommended it's also entirely optional.

Regards, Michael

--
For more ways to connect visit https://dart.dev/community
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/misc/CAF8T8LwU7-uD-DD4%3D7RDOtCbtCa38s2UV67Q_ARtLTbEH7%2Bq7A%40mail.gmail.com.

Chris Norman

unread,
Jun 15, 2021, 6:11:51 AM6/15/21
to mi...@dartlang.org
Bob,
I'd just like to say that I am totally blind, and as such am in literally the worst group to be picking my own visual style for absolutely anything. I personally entirely value dartfmt, and I love that in VS Code the Dart extension applies formatting as I go.

I find the tooling one of the things I like most about Dart, and it's really nice that I have found someone to direct my praise at. Well done with dartfmt, it certainly makes this particular developer's life better.

Take care,

Chris Norman



Guyren Howe

unread,
Jun 15, 2021, 10:37:54 AM6/15/21
to mi...@dartlang.org
The scoring on pub is the most obvious thing; also the formatter is encouraged in the tutorials and other places IIRC.

Also, responding to an earlier comment: git diff can (should!) be run in a ignore whitespace mode, so I see no obstacle to aligning things.

Anyway.

I was hoping to get a chorus of folks agreeing with me, which would encourage changes to the formatting. Since that hasn’t happened, I guess I’ll just keep doing my own thing.
Reply all
Reply to author
Forward
0 new messages