The order of 'Encapsulate field' loses dartdocs.

Currently when using Encapsulate field, the order of the generated values is private var, getter, setter.

It would make more sense to have the generated order be: getter, private var, then setter, instead of having the private var come first: if you had dartdoc documentation on the original var, then it will get lost when encapsulating, since dartdoc will now think the /// comment is on the private field.

For example, starting with:

  /// Counts the foos in a bar.
  int foo;

and you run “Encapsulate field” on foo, then you get:

  /// Counts the foos in a bar.
  int _foo;

  int get foo => _foo;

  set foo(int foo) {
    _foo = foo;
  }

Which means that dartdoc loses the original documentation, because it now sees that as attached to the private var, and not the getter, and so it needs to be moved manually.

It should generate it like this to retain the docs:

  /// Counts the foos in a bar.
  int get foo => _foo;

  int _foo;

  set foo(int foo) {
    _foo = foo;
  }

[scheglov]

Ah, I see. Of course Flutter has a bit different code style.

Hm… Honestly I’m not sure what to do here. This is not what most of the other code does.

We could go the way of making a lot of code style settings, somewhere in analysis_options.yaml - order of declarations, adding type for extracted locals, add or omit new keyword. Support for settings costs something, but if it is important, we could do this. @devoncarew @bwilkerson

[gspencergoog]

Well, it sure would be useful to have these actions be configurable. If you had those options, then you could also do something along the line of “Sort class members”, but have it apply the ordering in the options instead of sorting alphabetically.