Do people generally use dartfmt?

[Danny Tuppeny]

I've been running it on some code lately and I can't say I'm a fan... I think 80 characters is ridiculously short (every method signature seems to end up wrapped horribly) and code I split across multiple lines for readability is all being unwrapped.

Here's an example - the code on the left looks much better to me (it looks even better if we used tabs at 4x space, but meh), especially the method at the bottom (I don't think it'd look so bad with string.format, but it looks horrible like this).

So I'm wondering if people are actually using it? If general consensus is yes, I might make an effort, but otherwise I'm thinking of just ditching it and going with tabs.

[Joel Trottier-Hébert]

I personally use it on all my projects. I didn't like the 80 width by default. I'm still not a fan, but I'm more neutral to it than anything now. What I like about it, is when you contribute to a project that uses it, you don't have useless comments in pull requests about code style and all that.

If you had a big code base, and were many people to work on it, I wouldn't mind using another line width if that'd help you.

To do so, you can pass an argument to dartfmt to specify the line length.

ie:

dartfmt -l 120

Hope that helps you.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---
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.

[Joel Trottier-Hébert]

Also, offtopic a bit -- you should take a look at the http package, and also the usage of async/await (but I'm sure you know about the last one)

[Danny Tuppeny]

If you had a big code base, and were many people to work on it, I wouldn't mind using another line width if that'd help you.

To do so, you can pass an argument to dartfmt to specify the line length.

ie:

dartfmt -l 120

I did try a longer line width (it's a VS Code extension I'm working on, so I'm not actually using dartfmt directly, but through the Analysis Server) but it makes the issue shown at the bottom of my screenshot even worse (more stuff gets unwrapped onto long lines).

I think it's mostly OK, I just think it uses the line length really badly - it uses it as a max, and also as a "goal" in unwrapping things. If it just didn't remove linebreaks I'd inserted before dots, I'd probably be really happy with it (I'd set a longer line length, then not have the unwrapping)!

Also, offtopic a bit -- you should take a look at the http package, and also the usage of async/await (but I'm sure you know about the last one)

Cool, I didn't know about the http package (I did know about await). I've actually not written any Dart in years and this code was written a few weeks back with no editor help so it was a bit basic (it was the thing that motivated me to start Dart-Code!). I'm just about to go back and start tidying it up (to get some real usage of Dart-Code) :-)

[Jan Mostert]

Up the line-length to 120 and I'll probably use it, 80 is fine for normal OO code, but when you start in-lining some lambdas, you overrun the 80 character limit very quickly.

In the above screenshots, the "unformatted" code actually reads easier.

--
Jan Vladimir Mostert
janvladimirmostert.com

--

[Danny Tuppeny]

Up the line-length to 120 and I'll probably use it, 80 is fine for normal OO code, but when you start in-lining some lambdas, you overrun the 80 character limit very quickly.

The problem with upping the limit is that even more code gets unwrapped as shown at the end of the file and that really bugs me :(

I both like and dislike it's idea that you should always get the same output for the same input (ignoring whitespace), but some other editors (like Visual Studio) definitely allow you to manually insert linebreaks in some types of code and won't remove them (uesr knows best!).

I'll try it for a while and see how I get on. Doesn't seem like I'd be totally against the grain if I didn't use it.

 

 

In the above screenshots, the "unformatted" code actually reads easier.

My thoughts exactly :( 

[Steve Lympany]

Yes, I use it, and just expect it to be there.

I have some cases - parts of files - that I'd prefer to be excluded from formatting. Maybe a tag could be invented? Eg extending triple slash...

/// #*
Ignored code for formatting
..
/// *#

That could be extended to set line widths too, maybe?

Otherwise, for me, it just works fine. I haven't studied it much (maybe the above is already available!).
S

[Jan Mostert]

IntelliJ also doesn't remove manually added line-breaks or unwraps code that you've wrapped over multiple lines for readability, unless you have many blank lines, then it might compact them a bit.

Currently the IntelliJ formatter does a better job for us than the dart formatter does since we can specify line length of 120 as well as not lose developer-wrapped code.

Writing this:

blah.dosomething

      .dosomethingElse

      .uppercase

      .sort

      .filter

should never become: 

blah.dosomething.dosomethingElse

      .uppercase.sort.filter

There's reason I wrote it like in the first example
The first thing developers will now do is curse the previous dev who wrote it in such a bad format 

and re-format it like it originally was to be able to read it easier.

--
Jan Vladimir Mostert
janvladimirmostert.com

--

[Gonzalo Chumillas]

I use it from my Atom editor. It automatically formats the code just before saving it. But I would change some things. I have always used the PEAR's coding standards:

https://pear.php.net/manual/en/standards.php

It would be nice adopting that format. Or, at least, borrow some ideas from it. But it is better than using nothing.

[Bob Nystrom]

Replying to everything in one big ball:

On Fri, Aug 5, 2016 at 6:43 AM, Danny Tuppeny <da...@tuppeny.com> wrote:

I'm wondering if people are actually using it? If general consensus is yes, I might make an effort, but otherwise I'm thinking of just ditching it and going with tabs.

Yup, we require all internal Google Dart users to format with dartfmt (using the default 80 column line limit) in order to commit code. That's on the order of millions of lines of code.

Most (but, strangely not all) of the Dart code maintained by the Dart team is also formatted with dartfmt.

On Fri, Aug 5, 2016 at 6:43 AM, Danny Tuppeny <da...@tuppeny.com> wrote:

especially the method at the bottom (I don't think it'd look so bad with string.format, but it looks horrible like this).

I think it would look a little better if you weren't using ".." for the sort() call. If you don't want it to be one line, then going out of your way to make it one statement is a little odd.

After that, I'm personally fine with the method chain being all on one line.

I do prefer the 80 column limit. It causes some extra wrapping, but it means I don't have to awkwardly scroll horizontally to see all of the code like I have to do right now with your screenshot in gmail. :)

On Fri, Aug 5, 2016 at 6:58 AM, Danny Tuppeny <da...@tuppeny.com> wrote:

If it just didn't remove linebreaks I'd inserted before dots, I'd probably be really happy with it (I'd set a longer line length, then not have the unwrapping)!

Preserving some of your hand formatting, but not all of it, interferes with a lot of the goals of the formatter.

On Fri, Aug 5, 2016 at 7:35 AM, Steve Lympany <steve....@gmail.com> wrote:

I have some cases - parts of files - that I'd prefer to be excluded from formatting. Maybe a tag could be invented? Eg extending triple slash...

/// #*
Ignored code for formatting
..
/// *#

See here: https://github.com/dart-lang/dart_style/wiki/FAQ#why-cant-i-tell-the-formatter-to-ignore-a-region-of-code

On Fri, Aug 5, 2016 at 7:37 AM, Jan Mostert <jan.m...@gmail.com> wrote:

blah.dosomething

      .dosomethingElse

      .uppercase

      .sort

      .filter

should never become: 

blah.dosomething.dosomethingElse

      .uppercase.sort.filter 

This example is kind of confusing because you have a bunch of things that are syntactically properties (i.e. getters), but are named like they are methods ("dosomething").

The formatter is designed to do a good job on real-world code. You can always make non-idiomatic code that gets formatted weird because the formatter isn't tuned for that. If you were to make this example a little more realistic, like:

  blah

      .doSomething()

      .doSomethingElse()

      .uppercase

      .sorted

      .filter(() => stuff > whatever);

Then you will see it also formats it more like you prefer.

Cheers!

– bob

On Fri, Aug 5, 2016 at 8:03 AM, Gonzalo Chumillas <gonzalo....@gmail.com> wrote:

I use it from my Atom editor. It automatically formats the code just before saving it. But I would change some things. I have always used the PEAR's coding standards:

https://pear.php.net/manual/en/standards.php

It would be nice adopting that format. But it is better than using nothing.

[Danny Tuppeny]

especially the method at the bottom (I don't think it'd look so bad with string.format, but it looks horrible like this).

I think it would look a little better if you weren't using ".." for the sort() call. If you don't want it to be one line, then going out of your way to make it one statement is a little odd.

I didn't go out of my way to make it one statement, it just felt more natural (otherwise I'd have loads of variables only being used on the next line, which seems rather noisy).

I'm a total Dart noob though, so don't for a minute think this code is ideal. I'd be really interested to know how you'd write/format it though! A copy of the file is here:

https://gist.github.com/DanTup/2fbdde2b5c5a69520c56ba072ca28b7e

I do prefer the 80 column limit. It causes some extra wrapping, but it means I don't have to awkwardly scroll horizontally to see all of the code like I have to do right now with your screenshot in gmail. :)

To be fair, that's two screens side-by-side! :P

I've just got an ultrawide monitor (2660x1080) and I have all this width not being used... Even with two VS Code windows open (both with the explorer view down the side) 80 characters takes up hardly any of the screen.

I don't think constraining the width is a bad idea, it just feels like 80 is too short (and it feels like indenting with 2 spaces, which I think is also insane, was done because of this width) :(

If it just didn't remove linebreaks I'd inserted before dots, I'd probably be really happy with it (I'd set a longer line length, then not have the unwrapping)!

Preserving some of your hand formatting, but not all of it, interferes with a lot of the goals of the formatter.

Yeah, I get that. I can see both advantages and disadvantages to allowing the existing format to influence the output. However now it feels like I start tweaking my code just to try and get it to format in a readable way, and that kinda makes me question the use of it :(

The formatter is designed to do a good job on real-world code. You can always make non-idiomatic code that gets formatted weird because the formatter isn't tuned for that. If you were to make this example a little more realistic, like:

  blah

      .doSomething()

      .doSomethingElse()

      .uppercase

      .sorted

      .filter(() => stuff > whatever);

Then you will see it also formats it more like you prefer.

But presumably that only doesn't get unwrapped because the whole thing is too long? It seems weird that you could write two identical chunks like that, one 81 chars, one 79 and they would format very differently.

I presume the rules on the decisions the formatter uses aren't really documented other than in the source?

 

[Bob Nystrom]

On Fri, Aug 5, 2016 at 10:44 AM, Danny Tuppeny <da...@tuppeny.com> wrote:

especially the method at the bottom (I don't think it'd look so bad with string.format, but it looks horrible like this).

I think it would look a little better if you weren't using ".." for the sort() call. If you don't want it to be one line, then going out of your way to make it one statement is a little odd.

I didn't go out of my way to make it one statement, it just felt more natural (otherwise I'd have loads of variables only being used on the next line, which seems rather noisy).

I'm a total Dart noob though, so don't for a minute think this code is ideal. I'd be really interested to know how you'd write/format it though! A copy of the file is here:

https://gist.github.com/DanTup/2fbdde2b5c5a69520c56ba072ca28b7e

If it were my code, I'd do:

  String toQueryString(Map<String, String> data) {

    var items = data.keys.map((k) => "$k=${encode(data[k])}").toList();

    items.sort();

    return items.join("&");

  }

I do prefer the 80 column limit. It causes some extra wrapping, but it means I don't have to awkwardly scroll horizontally to see all of the code like I have to do right now with your screenshot in gmail. :)

To be fair, that's two screens side-by-side! :P

Right, but that's a typical use case when you're doing code reviews, looking at diffs, etc.

 

I've just got an ultrawide monitor (2660x1080) and I have all this width not being used...

Many users (including me, for what it's worth) do almost all of their work on a laptop screen.

When I do use a big monitor, I use the extra horizontal space for other columns, docs, other tool windows, etc.

Readability of text generally goes down when lines go above a certain length. The wider the line, the longer it takes your eye to track back to the beginning of the next line, and the greater chance of making mistakes and skipping or double-reading a line. That's why newspapers use several relatively columns of text on their big wide sheets of paper.

 

Even with two VS Code windows open (both with the explorer view down the side) 80 characters takes up hardly any of the screen.

I don't think constraining the width is a bad idea, it just feels like 80 is too short (and it feels like indenting with 2 spaces, which I think is also insane, was done because of this width) :(

I don't know where the 2 space thing comes from, but it's used in languages at Google that don't have the 80 column limit. We just followed other Google language styles that all use 2 spaces. It seems like most of the open source ecosystem is going in that direction too.

 

The formatter is designed to do a good job on real-world code. You can always make non-idiomatic code that gets formatted weird because the formatter isn't tuned for that. If you were to make this example a little more realistic, like:

  blah

      .doSomething()

      .doSomethingElse()

      .uppercase

      .sorted

      .filter(() => stuff > whatever);

Then you will see it also formats it more like you prefer.

But presumably that only doesn't get unwrapped because the whole thing is too long?

Right.

 

It seems weird that you could write two identical chunks like that, one 81 chars, one 79 and they would format very differently.

Well, we're talking about a tool whose job is to produce an optically-consumed output. Spatial dimensions matter.

I presume the rules on the decisions the formatter uses aren't really documented other than in the source?

Alas, no, though I have an issue to do that. I did write up how the formatter applies its rules, though. It's pretty complex.

The rules themselves are simpler, but they also have a good bit of sophistication in them. Like many user interface issues, what you intuitively think is simple when you do it manually actually turns out to have a large amount of subtlety that you aren't conscious of.

Cheers!

– bob

[Danny Tuppeny]

If it were my code, I'd do:

  String toQueryString(Map<String, String> data) {

    var items = data.keys.map((k) => "$k=${encode(data[k])}").toList();

    items.sort();

    return items.join("&");

  }

Hmmm, that does kinda look reasonable and fit within the 80 characters. See, it's just noobishness :)

(is it just me that hates that sort doesn't return the sorted list? performance sherformance!)

To be fair, that's two screens side-by-side! :P

Right, but that's a typical use case when you're doing code reviews, looking at diffs, etc.

It's not that common for me (I prefer inline diffs and use side-by-side rarely), but they're points. Actually, when I merge I end up with three columns on monitor and the output on a second, so maybe you're on to something. (.. that we should obviously stop doing code reviews (or at least merges!))

Many users (including me, for what it's worth) do almost all of their work on a laptop screen.

You just need to get 21:9 laptops! :)

(if they're not a thing; they should be)

 

Readability of text generally goes down when lines go above a certain length. The wider the line, the longer it takes your eye to track back to the beginning of the next line, and the greater chance of making mistakes and skipping or double-reading a line. That's why newspapers use several relatively columns of text on their big wide sheets of paper.

Yeah but newspapers are written for mortals and we are developers ;)

Seriously though, I think the reading is very different - for one, our code tends to always be indented, which the 80 chars doesn't consider. That said, Dart isn't as bad as some (C# namespace + class means we're in at 8 characters as a baseline, then every method body is at 12)!

I don't know where the 2 space thing comes from, but it's used in languages at Google that don't have the 80 column limit. We just followed other Google language styles that all use 2 spaces. It seems like most of the open source ecosystem is going in that direction too.

I don't think I will ever be convinced spaces are a good idea. Tabs allow devs to set their own widths, everyone is happy. Tabs for indenting, spaces for alignment. Simples! ;P

 

Alas, no, though I have an issue to do that. I did write up how the formatter applies its rules, though. It's pretty complex.

Cool, looks an interesting post, I'll have a read through. I quietly hoped your blog would be wider than 80 characters but it is not. You win this time!

[Don Olmstead]

I do not use dartfmt. I think Bob's done an impressive bit of engineering with it but its not to the point where I would use it.

It produces some really ugly formatting in a lot of cases for my code. As an example.

Iterable<Metadata/*=T*/>

   classMetadataQueryAll/*<T extends Metadata>*/(ClassMetadata clazz,

                                                 MetadataMatchFunction matcher,

                                                {bool includeFields: defaultInclude,

                                                 bool includeConstructors: defaultInclude,

                                                 bool includeMethods: defaultInclude}) =>

        _expandClassMetadata/*<T>*/(

            clazz,

            includeFields,

            includeConstructors,

            includeMethods

        ).where(matcher);

Becomes

Iterable<Metadata/*=T*/ > classMetadataQueryAll/*<T extends Metadata>*/(

        ClassMetadata clazz, MetadataMatchFunction matcher,

        {bool includeFields: defaultInclude,

        bool includeConstructors: defaultInclude,

        bool includeMethods: defaultInclude}) =>

    _expandClassMetadata/*<T>*/(

            clazz, includeFields, includeConstructors, includeMethods)

        .where(matcher);

[Danny Tuppeny]

That is a bit naff, though I can't but think those weird comments aren't helping - what are they?

I wonder if they're open to changes to the formatter or if they consider that making changes would somewhat defeat the idea of all the code being the same..

 

[Don Olmstead]

Generic method syntax.

[Danny Tuppeny]

I'm confused - is that a first-class Dart thing, or some additional tool/checker? Using comments for stuff doesn't seem very Dart-like?

[Don Olmstead]

https://chromium.googlesource.com/external/github.com/dart-lang/dev_compiler/+/refs/heads/master/doc/GENERIC_METHODS.md

[Danny Tuppeny]

Ah cool; thanks for the info - seems like it's just temporary then :)

[Don Olmstead]

Yes but the code will still end up getting mangled quite a bit by the formatter.

[Danny Tuppeny]

Sure; I was going off on a bit of a tangent because stuff in comments kinda bugs me :)

Based on the discussion here, I'm gonna give the formatter a better go. I'll leave it set to 80 and see how I get on for a bit. I really haven't written much Dart (I never got on with any of the editors) so possibly it'll feel less weird over time.

[Don Olmstead]

Definitely give it a go. In my case I don't like the output when it decides to jam stuff on a single line. If that were to change I'd run all my code through it.

[Alec Henninger]

You could probably take any code snippet, think long and hard about its artful indentation, and create a more delightful organization of code than dartfmt would produce... to you. The value to me is that dartfmt is completely automated, deterministic, and the results are pretty good for most people (something humans can also have a hard time with). Consistent formatting also reduces merge conflicts and diff distractions. I think the practical benefits make the occasional less than ideal formatting more than forgivable. The time and stress savings make dartfmt a joy to use if you (and your team) are able to let go a little on what you may prefer.

[Filip Hracek]

I'm just here to say that I use dartfmt on everything (Atom does that automatically, and I have a keymapping in IntelliJ) and stay with 80 char width everywhere, and not just on internal Google projects (where it's required). 

It may have seem arbitrary at first (consider that the first time I was forced to do 80 chars was with Java...) but I'd never go back.

Benefits:

• shorter lines are generally (= not all the time, but most of the time) more readable
• allows to have multiple files open on a big screen (or one file on multiple places) — increases my productivity a lot
• forces you to write better code (once you're indented so much to the right that the 80 chars limit leads to absurdly formatted code, you know you need to refactor)

I completely understand there are also drawbacks, but for me personally they're overridden by the benefits above.

Filip Hráček
https://google.com/+filiphracek

[DoHyung Kim]

My team use dart_style with 80 column limit. We do use Dart as our main language.

Having worked on embedded systems over 10 years, I've tried various coding conventions and put much effort in manually wrapping lines and aligning them. I mainly wrote C and Java but almost never used IDEs then (my choice of editor was vi). But my conclusion was any single convention doesn't make huge enough difference in readability compared to the others, though I prefer 80 column limit to longer limits. I found it's far more difficult to let all team members agree on and committed to single convention.

So after moving to server-side Java, I gave Eclipse's formatter a try and got to conclude that the output is good enough and I can sacrifice some formatting excellence for saving time to go into manual formatting, which I can put into other tasks. Also reading many OSS Java projects, the formatting specifics haven't too much problem to me.

In Go, its grammatical rule practically prohibits some formatting variant which was possible in other C-like languages with curly brace. Frankly I like that level of enforcement. ;)

So I'm happy with dart_style.

I know and admit that there are pros and cons in every approach. But I hope to say that here is a team which is happy with the way dart_style works.

DoHyung

2016년 8월 5일 금요일 오후 10시 43분 16초 UTC+9, Danny Tuppeny 님의 말:

[DoHyung Kim]

It seems that I mixed coding convention and finer granular formatting issues. But my point was that I think even the suboptimal formatting is good enough to me considering the benefit we have with formatters.

2016년 8월 6일 토요일 오후 3시 13분 32초 UTC+9, DoHyung Kim 님의 말:

[Anders Holmgren]

It's an interesting topic code formatting. People tend to have rather strong opinions, but interestingly I've noticed with myself, that what I feel strongly about is fairly malleable.

I remember when I first came across dart's 80 char rule I reacted strongly against it. I thought it silly in todays world with the amazing screens we have.

I vented my complaint and Bob gave his justification. I didn't really buy it at the time but I am very pro auto-formatting so thought I'd give it a go.

Since the code took up less width of my screen I moved intellij's structure panel to be always visible on the right and the project panel always visible on the left with the code panel in between.

In time I became so used to that that I now cringe when editing Java code at work and find myself making that code closer to 80 chars.

For me, dartfmt does a 'good enough' job that I always use it and much prefer it when everyone has it turned on if I need to edit their code. 

I much prefer a world where everyone uses exactly the same 'good enough' formatter than one in which everyone manually formats code to their own 'perfect' ideal. 

Vote 1: Fascist enforcement of code formatting!! 

[Günter Zöchbauer]

80 chars on modern screens seems ridiculous but if I want to read a file on GitHub directly without checking the code out locally to open it in my favorite IDE I'm glad the author didn't use longer lines.

In my IDE it has the advantage, that I can have 2 or 3 files side-by-side easily.

I wouldn't want to contribute to a Dart project that doesn't use dartfmt. It's not always perfect but a single keystroke and it's good enough and consistent across all files of a project and all projects.

Formatting code manually seems like a good way to me to waste time for nothing.

[Danny Tuppeny]

On Mon, 8 Aug 2016 at 09:26 Günter Zöchbauer <gzo...@gmail.com> wrote:

80 chars on modern screens seems ridiculous but if I want to read a file on GitHub directly without checking the code out locally to open it in my favorite IDE I'm glad the author didn't use longer lines.

In my IDE it has the advantage, that I can have 2 or 3 files side-by-side easily.

I wouldn't want to contribute to a Dart project that doesn't use dartfmt. It's not always perfect but a single keystroke and it's good enough and consistent across all files of a project and all projects.

I think I basically agree now, but...

Formatting code manually seems like a good way to me to waste time for nothing.

There is a difference between "formatting to meet some rules" and "typing it in a way that is readable".

I think it's probably worth using dartfmt but I'm still on the fence about whether completely ignoring the users preferences is being completely offset.

That said, I've often wondered why we can't customise formatting more for the visible document in our IDEs.. Why can't we set our own formatting rules in the IDE but have the saved file always the dartfmt'd version? Want braces in the correct places? Fine! Want to indent (correctly ;)) with tabs? Want all method/ctor signatures on one line? Fine!

I'm not saying there aren't complications; but imagine if dartfmt accepted dynamic rules and the IDE applies one set during load and another during save! =)

[Bob Nystrom]

On Sun, Aug 7, 2016 at 3:33 AM, Anders Holmgren <andersm...@gmail.com> wrote:

Vote 1: Fascist enforcement of code formatting!! 

There is no voting in fascism!

– bob

[Günter Zöchbauer]

That's an interesting idea. I guess version comparisons don't work when there are such differences even though they are only white spaces.

[Danny Tuppeny]

On Tue, 9 Aug 2016 at 18:42 Günter Zöchbauer <gzo...@gmail.com> wrote:

That said, I've often wondered why we can't customise formatting more for the visible document in our IDEs.. Why can't we set our own formatting rules in the IDE but have the saved file always the dartfmt'd version? Want braces in the correct places? Fine! Want to indent (correctly ;)) with tabs? Want all method/ctor signatures on one line? Fine!

I'm not saying there aren't complications; but imagine if dartfmt accepted dynamic rules and the IDE applies one set during load and another during save! =)

That's an interesting idea. I guess version comparisons don't work when there are such differences even though they are only white spaces.

I guess you would always compare the same (eg. if your IDE is doing the diff, reformat the version you're comparing to... for an external tool just compare those on disk which are both the "save formatting").

I'm sure there would be edge cases, but maybe they're solvable. Would be interesting to see someone attempt it!

[Matan Lurey]

Usually having customizable formatters, especially at Google-scale, is a recipe for lots of disagreement and differences between projects.

At least internally there is of course lots of personal preferences on how they wish formatting works, but we've generally agreed having 'dartfmt' as a standard 1-way to do formatting makes code reviews simpler (no personal preferences enforced) and allows things like generated code to share the same formatting.

--

[Danny Tuppeny]

On Tue, 9 Aug 2016 at 19:38 Matan Lurey <ma...@lurey.org> wrote:

Usually having customizable formatters, especially at Google-scale, is a recipe for lots of disagreement and differences between projects.

At least internally there is of course lots of personal preferences on how they wish formatting works, but we've generally agreed having 'dartfmt' as a standard 1-way to do formatting makes code reviews simpler (no personal preferences enforced) and allows things like generated code to share the same formatting.

These last comments weren't about custom formatting for sharing, they were about the idea of letting the IDE show a personally customised representation to you that is disconnected from what's on the disk :-)

[Anders Holmgren]

> IDE show a personally customised representation to you that is disconnected from what's on the disk :-)

That sounds a bit like personally configurable tab indent size and we know how that ended ;-)

--

For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---

You received this message because you are subscribed to a topic in the Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit https://groups.google.com/a/dartlang.org/d/topic/misc/P56eCKMiP7Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to misc+uns...@dartlang.org.

[Anders Holmgren]

You can always vote fascism in you just can't vote it back out ;-)

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---

You received this message because you are subscribed to a topic in the Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit https://groups.google.com/a/dartlang.org/d/topic/misc/P56eCKMiP7Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to misc+uns...@dartlang.org.

[Danny Tuppeny]

On Tue, 9 Aug 2016 at 21:40 Anders Holmgren <andersm...@gmail.com> wrote:

> IDE show a personally customised representation to you that is disconnected from what's on the disk :-)

That sounds a bit like personally configurable tab indent size and we know how that ended ;-)

It works perfectly as far as I'm concerned! If you want 2, 4 or 8, indenting with tabs you can have it =)

If people are using tabs for alignment though, then that's their own fault (or actually, in many cases, their IDEs fault for not letting them mix them)!

But, I think this is totally different. The only issues with tabs (or spaces) is that people are sharing stuff that's affected by them. My suggestion here was to totally disconnect what you see on screen from the file - no matter what your preferences, they wouldn't change the file on disk at all.

[Don Olmstead]

http://nickgravgaard.com/elastic-tabstops/

--

For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---

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.

[Weiping Chen]

The only election that I could vote in Communist China, there was only ONE candidate and a blank for you to write in.

[Thomas Løcke]

My team use dartfmt, with no special options set. It is wonderful not having to waste time on how the code is supposed to look.

dartfmt = consistency, which becomes increasingly important as the size of a team/project goes up.