[Dot shorthands] A new lint and fix to prefer dot shorthands

[alex-medinsh]

The new dot shorthands feature looks very nice and makes the code cleaner (in most cases). I wish there was a linter rule (and maybe a dart fix) to prefer the shorthand form over the long form, to enforce a single style in a codebase.

I am not yet convinced that all types of shorthands are more readable, so I propose the lints are split for all the different types: enums, constructors, static members etc, so they can be enabled individually.

[FMorschel]

Linking with #60824

@bwilkerson

[alex-medinsh]

I understand the decision in the linked issue was to wait and get some feedback from the users, but I feel like the lack of lints makes the feature less discoverable. Looking at the examples in the documentation gave me some understanding of where the different types of shorthands can be used, but I still don't fully understand how this applies to my codebase.

[bwilkerson]

The reason we closed the linked issue is not because we don't want such a lint, it's because it became obvious that the lint was difficult to design. Doing the design work would be a prerequisite to implementing the lint, so if you have input on how the lint should work (what should be flagged and what shouldn't) we'd love to hear it.

I am not yet convinced that all types of shorthands are more readable, so I propose the lints are split for all the different types: enums, constructors, static members etc, so they can be enabled individually.

Exactly. Except it also isn't clear whether it's the kind of declaration being referenced that determines whether a dot shorthand should be used, or whether it's the location at which the reference occurs. Or both. Or something else entirely.

... I feel like the lack of lints makes the feature less discoverable.

I agree, which I why I proposed the lint in the first place.

... I still don't fully understand how this applies to my codebase.

I might be able to help with that. The original motivation for the feature was to allow redundant information to be removed, making the code cleaner. So the places you should consider using the feature are exactly those places where some code is redundant and you don't need it in order to understand what's going on.

For example, if you're creating a Column using something like this

Column(mainAxisAlignment: MainAxisAlignment.center, ...)

You could drop the class name, because it matches the parameter type, and just write

Column(mainAxisAlignment: .center, ...)

If you find that more readable, then you should use the feature. If you don't, you shouldn't use it.

[rekire]

As mentioned on the Discord server I build for me this regular expression:

(?:CrossAxisAlignment|MainAxisAlignment|MainAxisSize|TextBaseline|Axis)(\.[^.(\n,]*?)( => |\|\||\)|:|;|,)

which can be replaced by $1$2. It might help others (keep in mind to enable RegEx and case sensitive in the global replacement of Android Studio).

IMHO that can be extended for all cases where the "base class" is an enum. Just the case final newAxis = condition ? .horizontal : .vertical would not work without mentioning the enum class.

[FMorschel]

Just the case final newAxis = condition ? .horizontal : .vertical would not work without mentioning the enum class.

Cases like this can also be handled by our tooling if they are designed to do it. We simply add the enum type name once in the variable declaration before the variable name (like final MyEnum newAxis. With that, your expression does work with dot-shorthands.

[huanghui1998hhh]

For developers who need dot shorthand linter, I've created a package prefer_shorthands as a temporary solution. Currently, it ignore two scenarios: default constructor calls like A() and implicit type declarations like final a = String.fromCharCode(96). Note that the package likely has other edge cases that aren't yet covered. There's also a known limitation: I haven't figured out how to make the analyzer_plugin work alongside dart fix (you can still use quick-fix).

[bwilkerson]

I haven't figured out how to make the analyzer_plugin work alongside dart fix ...

That's because this isn't yet supported. We will likely add support for plugins to contribute to dart fix in the future, but it isn't there today.

[huanghui1998hhh]

@bwilkerson Another question, is there some way to write test for CorrectionProducer?

[FMorschel]

@huanghui1998hhh, not yet. Follow this issue:

• [analyzer_testing] Expose tools to test assists/fixes #61785

I've shared there an MIT licensed project that has a workaround for this. Copying what the SDK tests do to test them.

[vincent-hoodoo]

One thing I've come to really appreciate about dart is that its style can be really opinionated, via its formatter or via extensive sets of analysis rules like the one in very_good_analysis.

It makes it possible for teams to avoid eternal discussions about what style they should choose. In my team, we never waste time discussing style: we all write dart code the same way, following strict sets of rules enforced by the analyzer and the formatter.

I'm really hoping that we don't have to start having long discussions about dot shorthands, so these rules would be very welcome!