Dart-Code
Inconsistent comma insertion at code completion
When auto-complete named parameter, a trailing comma will be inserted for flutter classes but not for user-defined classes.
@bwilkerson @pq there is some specific handling for expressions that create Flutter widgets here (added here as part of this issue):
https://github.com/dart-lang/sdk/blob/master/pkg/analysis_server/lib/src/services/completion/dart/arglist_contributor.dart#L111-L112
The same logic is used in a few other places (like the "add required arguments" quick-fix). My guess is that the feeling was that adding them always would add them in places they're not wanted (for example short calls like _addDefaultParamSuggestions(parameters, appendComma: true); in the source above) too often, but it's fairly certain they're wanted in Flutter code.
There is a lint require_trailing_commas that is already used in a few places to enable trailing commas, but I don't if it being enabled is a strong enough signal that they would always be wanted (since the lint only flags calls that wrap, and not short calls - something we don't know at the time the call is being written). I'm not sure it'd be easy to know when the user wants them, but having the option to have them always inserted (and having to delete when they're not required) might be a fair request.
I noticed some code for "code style options".. is the idea to have customisation options that are not driven by lints, and if so is it something that might fit there? (If so, should we move this to the SDK and add it to https://github.com/dart-lang/sdk/issues/49558?).
there is some specific handling for expressions that create Flutter widgets ...
My opinion is that the referenced code is an unfortunate (though pragmatic) work around to users not being able to specify their coding style preferences. I think it would be better to clean up this kind of code.
There is a lint require_trailing_commas that is already used in a few places to enable trailing commas, but I don't if it being enabled is a strong enough signal that they would always be wanted ...
The way the lint is defined, it's definitely not a signal that commas are always desired. The lint has an exception for code that fits on a single line. But as you noted, we can't tell what dart format will do with the line before we've made the edit, so we can't even conform to what the lint does signal.
I noticed some code for "code style options".. is the idea to have customisation options that are not driven by lints, and if so is it something that might fit there?
The class CodeStyleOptions is intended to be the singular interface for accessing any information available about what the user's style preferences are. That includes any style preferences we can glean from lints that are enabled as well as any other signals we might have.
We have discussed the possibility of adding support for expressing other kinds of style preferences to the analysis options file. I'm not sure we're ready to commit to that approach, but that would be one possible way to support a more explicit option.
It would make sense to introduce a method here to control whether or not to insert a trailing comma. That method wouldn't have many signals, but for now it could work like _isInFlutterCreation(). As we improve the information we have we could at least ensure that those improvements were being applied everywhere. And one of the first improvements might be to consider the parameter lists of constructors of any subclass of Widget to be a Flutter creation context.
