dart-lang / linter

Linter for Dart.

Linter for Dart

Repository has moved

The Dart linter is now developed within the Dart SDK repository, and can be found at https://github.com/dart-lang/sdk/tree/main/pkg/linter.

For now, please continue to file new linter issues on this repository. To contribute changes, check out the SDK contribution guide.

---

The Dart Linter package defines lint rules that identify and report on "lints" found in Dart code. Linting is performed by the Dart analysis server and the dart analyze command in the Dart command-line tool.

Installing

The linter is bundled with the Dart SDK; if you have an updated Dart SDK already, you're done!

Alternatively, if you want to contribute to the linter or examine the source, clone the linter repo like this:

$ git clone https://github.com/dart-lang/linter.git

Usage

The linter gives you feedback to help you catch potential errors and keep your code in line with the published Dart Style Guide. Enforceable lint rules (or "lints") are cataloged here and can be configured via an analysis options file. The linter is run from within the dart analyze command-line tool shipped with the Dart SDK. Assuming you have lints configured in an analysis_options.yaml file at the root of your project with these contents:

linter:
  rules:
    - annotate_overrides
    - hash_and_equals
    - prefer_is_not_empty

you could lint your package like this:

$ dart analyze .

and see any violations of the annotate_overrides, hash_and_equals, and prefer_is_not_empty rules in the console. To help you choose the rules you want to enable for your package, we have provided a complete list of rules with lints recommended by the Dart team collected in package:lints. Lints recommended for Flutter apps, packages, and plugins are documented in package:flutter_lints.

If a specific lint warning should be ignored, it can be flagged with a comment. For example,

   // ignore: camel_case_types
   class whyOhWhy { }

tells the Dart analyzer to ignore this instance of the camel_case_types warning.

End-of-line comments are supported as well. The following communicates the same thing:

   class whyOhWhy { // ignore: camel_case_types

To ignore a rule for an entire file, use the ignore_for_file comment flag. For example,

// ignore_for_file: camel_case_types

...

class whyOhWhy { }

tells the Dart analyzer to ignore all occurrences of the camel_case_types warning in this file.

As lints are treated the same as errors and warnings by the analyzer, their severity can similarly be configured in an options file. For example, an analysis options file that specifies

linter:
  rules:
    - camel_case_types
analyzer:
  errors:
    camel_case_types: error

tells the analyzer to treat camel_case_types lints as errors. For more on configuring analysis see the analysis option file docs.

Contributing

Feedback is greatly appreciated and contributions are welcome! Please read the contribution guidelines; mechanics of writing lints are covered here.

Features and bugs

Please file feature requests and bugs in the issue tracker.

linter's Issues

Lint for CamelCase type names (Style Guide).

From the style guide:

DO name types using UpperCamelCase.

Classes and typedefs should capitalize the first letter of each word (including the first word), and use no separators.

GOOD:

class SliderMenu {
  // ...
}

class HttpRequest {
  // ...
}

typedef num Adder(num x, num y);

Lint for package dependency should/shouldn't be a dev dependency

If a dependency is used in bin/lib it MUST be a non-dev dependency
If a dependency is not used in bin/lib it SHOULD be a dev dependency

Minimal Config for Testing

Separate from the larger question of configurability in general (#7), we need a minimal config format for testing purposes. Whatever it ends up being, it should be labeled as provisional and consider it entirely subject to review and change.

Minimally, I'd like to see ways to:

• include/exclude files
• enable/disable specific rules

Lint for lowercase_with_underscores library prefixes (Style Guide)

DO use lowercase_with_underscores when specifying a library prefix.

GOOD:

import 'dart:math' as math;
import 'dart:json' as json;
import 'package:js/js.dart' as js;
import 'package:javascript_utils/javascript_utils.dart' as js_utils;

BAD:

import 'dart:math' as Math;
import 'dart:json' as JSON;
import 'package:js/js.dart' as JS;
import 'package:javascript_utils/javascript_utils.dart' as jsUtils;

Linter Configurability

Migrated from dartbug.com/22002:

Some amount of configurability would be nice eventually. Groups of rules to include/exclude, such as excluding the PREFER/AVOID rules or equivalently only including DO/DONT rules. Alternatively each rule can have an ID (same as might be used by the output or #88), and configuration can happen at that level. The config could be specified by something like a .dartformatrc in the project root i.e. something that is shared with a team via source control. This is how jshint and jscs specify their config for example. Might be nice to integrate with .editorconfig as well (this could replace the current line length option and many others that may be requested in the future).

Lint for package-prefixed library names (Style Guide)

DO prefix library names with the package name and a dot-separated path.

This guideline helps avoid the warnings you get when two libraries have the same name. Here are the rules we recommend:

• Prefix all library names with the package name.
• Make the entry library have the same name as the package.
• For all other libraries in a package, after the package name add the dot-separated path to the library’s Dart file.
• For libraries under lib, omit the top directory name.

For example, say the package name is my_package. Here are the library names for various files in the package:

GOOD:

// In lib/my_package.dart
library my_package;

// In lib/other.dart
library my_package.other;

// In lib/foo/bar.dart
library my_package.foo.bar;

// In example/foo/bar.dart
library my_package.example.foo.bar;

// In lib/src/private.dart
library my_package.src.private;

Lint for lowerCamelCase non-constant identifiers (Style Guide).

DO name non-constant identifiers using lowerCamelCase.

Class members, top-level definitions, variables, parameters, and named parameters should capitalize the first letter of each word except the first word, and use no separators.

GOOD:

var item;

HttpRequest httpRequest;

align(clearItems) {
  // ...
}

Hint to me when I have nullable fields in an object

The following construct should be avoided:

class Thing {
  double x;
  double y;
  double z;

  Thing(this.x, this.y, this.z);
  Thing.empty() {}
}

Issues are:

• x, y, and z could become null if Thing is constructed via empty().

The VM has a hard time optimizing fields that could be double or null. dart2js has a hard time optimizing field access that could be null.

Of course, I could set x,y,z to final. Or, I could eliminate empty() constructor.

Lint to prefer providing type annotations on public APIs (Style Guide).

From effective dart:

DO type annotate public APIs.

Type annotations are important documentation for how a library should be used.
Annotating the parameter and return types of public methods and functions helps
users understand what the API expects and what it provides.

Note that if a public API accepts a range of values that Dart's type system
cannot express, then it is acceptable to leave that untyped. In that case, the
implicit dynamic is the correct type for the API.

For code internal to a library (either private, or things like nested functions)
annotate where you feel it helps, but don't feel that you must provide them.

BAD:

install(id, destination) {
  // ...
}

Here, it's unclear what id is. A string? And what is destination? A string
or a File object? Is this method synchronous or asynchronous?

GOOD:

Future<bool> install(PackageId id, String destination) {
  // ...
}

With types, all of this is clarified.

Lint for lowercase_with_underscores library names and source files (Style Guide)

DO name libraries and source files using lowercase_with_underscores.

Some file systems are not case-sensitive, so many projects require filenames to be all lowercase. Using a separate character allows names to still be readable in that form. Using underscores as the separator ensures that the name is still a valid Dart identifier, which may be helpful if the language later supports symbolic imports.

GOOD:

• slider_menu.dart
• file_system.dart
• library peg_parser;

BAD:

• SliderMenu.dart
• filesystem.dart
• library peg-parser;

Lint to avoid wrapping fields in getters and setters just to be “safe” (Style Guide)

From the style guide:

AVOID wrapping fields in getters and setters just to be “safe”.

In Java and C#, it's common to hide all fields behind getters and setters (or properties in C#), even if the implementation just forwards to the field. That way, if you ever need to do more work in those members, you can without needing to touch the callsites. This is because calling a getter method is different than accessing a field in Java, and accessing a property isn't binary-compatible with accessing a raw field in C#.

Dart doesn’t have this limitation. Fields and getters/setters are completely indistinguishable. You can expose a field in a class and later wrap it in a getter and setter without having to touch any code that uses that field.

GOOD:

class Box {
  var contents;
}

BAD:

class Box {
  var _contents;
  get contents => _contents;
  set contents(value) {
    _contents = value;
  }
}

Lint to use curly bodies for statements except one-line ifs (Style Guide).

Migrated from dartbug.com/22001:

Should warn or fix if a for, while, or else clause does not have a curly brace body. It should also flag the then clause of an if if it doesn't fit on a single line.

[DISABLED] Lint to prefer using a public final field instead of a private field with a public getter (Style Guide)

From the style guide:

PREFER using a public final field instead of a private field with a public getter.

If you have a field that outside code should be able to see but not assign to (and you don’t need to set it outside of the constructor), a simple solution that works in many cases is to just mark it final.

GOOD:

class Box {
  final contents = [];
}

BAD:

class Box {
  var _contents;
  get contents => _contents;
}

Lint for one-member abstract class when a simple function will do (Style Guide).

From the style guide:

AVOID defining a one-member abstract class when a simple function will do.

Unlike Java, Dart has first-class functions, closures, and a nice light syntax for using them. If all you need is something like a callback, just use a function. If you're defining an class and it only has a single abstract member with a meaningless name like call or invoke, there is a good chance you just want a function.

GOOD:

typedef bool Predicate(item);

BAD:

abstract class Predicate {
  bool test(item);
}

Fix favicon for dart-lang.github.io/dart_lint.

Playing around with docs for rules over here:

http://dart-lang.github.io/dart_lint/lints/

and I can't seem to get the favicon to be picked up. I put it here

http://dart-lang.github.io/dart_lint/favicon.ico

thinking that's all I needed to do but no dice!

Surely something obvious...

Define style guide as data interchange format

Currently the style guide is just a markdown doc. So there is no metadata about the style guide rules for the linter to consume, so it will have to define its own. It would be much nicer if the lints produced by the linter were associated back to a style guide rule via a rule id. The rule metadata could then be looked up in the style guide by that id. Would probably be either JSON or YAML. That would allow:

• maintaining rule metadata in a single place
  • id
  • type e.g. DO/DONT/PREFER/AVOID
  • title the text after the type
  • description
  • good and bad examples
• Contextual view of style guide rule violations for lints in editors (e.g. in tooltips and problems view) which could also link to the appropriate section of the actual style guide.
• Filtering of rules by their type which could be useful for #7.
• Generating the actual style guide markdown doc.

I filed the issue here instead of at https://github.com/dart-lang/www.dartlang.org since this seems like a logical place for the discussion, but I can move it there if desired.

@pq @munificent thoughts?

Lint for pub package names.

DO use lowercase_with_underscores for package names.

From the Pubspec format description:

Package names should be all lowercase, with underscores to separate words, just_like_this. Use only basic Latin letters and Arabic digits: [a-z0-9_]. Also, make sure the name is a valid Dart identifier—that it doesn’t start with digits and isn’t a reserved word.

Bad location caching for pubspec lint reporting.

Specifically, this

library library_names;

yields:

[lint] DO use `lowercase_with_underscores` for package names. (tool/rule.dart, line 1, col 6)

(And shouldn't.)

Lint for braces in empty constructor bodies (Style Guide)

From the style guide:

DO use ; instead of {} for empty constructor bodies.

In Dart, a constructor with an empty body can be terminated with just a semicolon. This is required for const constructors. For consistency and brevity, other constructors should also do this.

GOOD:

class Point {
  int x, y;
  Point(this.x, this.y);
}

BAD:

class Point {
  int x, y;
  Point(this.x, this.y) {}
}

Lint for unused package defined in pubspec

Lint for unspecified version constraints on packages

Lint for empty catch blocks

This is a code smell and would be great if the linter could inform about it.

Lint for placing super() last in constructor initializers (Style Guide)

From the style guide:

DO place the super() call last in a constructor initialization list.

Field initializers are evaluated in the order that they appear in the constructor initialization list. If you place a super() call in the middle of an initializer list, the superclass’s initializers will be evaluated right then before evaluating the rest of the subclass’s initializers.

What it doesn’t mean is that the superclass’s constructor body will be executed then. That always happens after all initializers are run regardless of where super() appears. It’s vanishingly rare that the order of initializers matters, so the placement of super() in the list almost never matters either.

Getting in the habit of placing it last improves consistency, visually reinforces when the superclass’s constructor body is run, and may help performance.

GOOD:

View(Style style, List children)
    : _children = children,
      super(style) {

BAD:

View(Style style, List children)
    : super(style),
      _children = children {

Lint to split comments when > line length

Migrated from dartbug.com/22003:

I ran dartformat like this:

dartformat -l 58 -w *.dart

The input file included these two lines:

  // _cache is library-private, thanks to the _ in front of its name.
  static final Map<String, Logger> _cache = <String, Logger>{};

The output for those lines was this:

  // _cache is library-private, thanks to the _ in front of its name.
  static final Map<String, Logger> _cache =
      <String, Logger>{};

I expected something like this:

  // _cache is library-private, thanks to the _ in front
  // of its name.
  static final Map<String, Logger> _cache =
      <String, Logger>{};

Lint for type annotated formal initializers (Style Guide)

From the style guide:

DON’T type annotate initializing formals.

If a constructor parameter is using this. to initialize a field, then the type of the parameter is understood to be the same type as the field.

GOOD:

class Point {
  int x, y;
  Point(this.x, this.y);
}

BAD:

class Point {
  int x, y;
  Point(int this.x, int this.y);
}

Lint for using /// instead of /** for doc comments

https://www.dartlang.org/articles/style-guide/#do-use-doc-comments-when-commenting-members-and-types

This rule is actually specified as detail text within the above linked rule, where it says "Although Dart supports two syntaxes of doc comments (/// and /**), we prefer using /// for doc comments.

So it might worth updating the style guide to have a separate rule which says "PREFER to use /// for doc comments." (Actually, I'd want it to be DO, but not sure how many /** supporters are out there).

There is lots of old code that still uses /**, and it's quite tedious to convert them to ///, so a quick fix for this will be quite handy!

Lint for assignment to function/method parameter

int someFunc(var p) {
  p = 1;
} 

README is missing contextual info

• What is this lib?
• Why do I want it?
• What does it do?
• How do I file issues?

Lint for missing type info in formal parameter

Discovered in the wild a number of cases like this:

typedef A(B);
typedef B(dynamic);

Both of them are essentially equivalent to dynamic->dynamic which is most likely not what the user has in mind. Instead, they likely mean:

typedef A(B _);
typedef B(dynamic _);

As Paul Berry points out it's a nasty user trap in the language, especially for people coming from a C/C++ background where using a single identifier as a formal parameter denotes the type of the formal parameter. A proposed lint:

whenever a single identifier is used to name a formal parameter, check the enclosing scope to see if
the name shadows a type. If it does, give a hint because the user probably meant the identifier to
denote the type of the formal parameter. We could even add a quick fix which adds "_" as the
parameter name.

Lint for UpperCamelCase classes intended as metadata annotations (Style Guide).

DO use UpperCamelCase names for classes intended to be used in metadata annotations.

If the annotation takes no parameters, you might want to create a lowerCamelCase constant for it.

GOOD:

@Foo(anArg)
class A { ... }

@Foo()
class B { ... }

@foo
class C { ... }

Lint for unspecified type arguments when a type parameter has an upper bound.

Or more assertively:

DO: specify a type argument when a type parameter has an upper bound.

As a motivational example take the dart:math Point class:

class Point<T extends num>

The trouble is that this is legal:

Point p = new Point('hello', 'world');

and only fails at runtime if magnitude is called:

Unhandled exception:
type 'String' is not a subtype of type 'int' of 'times'.

To be sure Point is a special case but a general rule might be useful since in general if an upper bound has been defined dynamic is almost certainly not what's intended.

Complaints about this library declaration which seems valid to me.

library bwu_server.shared.datastore.some_file;

DO name libraries and source files using lowercase_with_underscores. (.../my_package/lib/src/shared/datastore/some_file.dart, line 1, col 1)

Are you interested in such bug reports already?

Fix false positives in "Prefer finals over getters" rule.

As @zoechi pointed out on #23, we need to refine our check to ensure we don't flag cases where the field is written to outside a constructor initializer.

In other words, this should produce a lint:

class A {
  var _a;
  var get a => _a; //LINT
  A(this._a);
}

But this should not:

class A {
  var _a;
  var get a => _a; //OK!
  A() {
    _init();
  }

  _init() {
   _a = 42;
  }
}

Lint to prefer lowerCamelCase for constant names. (Style Guide)

PREFER using lowerCamelCase for constant names.

In new code, use lowerCamelCase for constant variables, including enum values.

In existing code that uses ALL_CAPS_WITH_UNDERSCORES for constants, you may continue to use all caps to stay consistent.

GOOD:

const pi = 3.14;
const defaultTimeout = 1000;
final urlScheme = new RegExp('^([a-z]+):');

class Dice {
  static final numberGenerator = new Random();
}

BAD:

const PI = 3.14;
const kDefaultTimeout = 1000;
final URL_SCHEME = new RegExp('^([a-z]+):');

class Dice {
  static final NUMBER_GENERATOR = new Random();
}

Just read "Contributions welcome!" and I want to ask "what this small product can do right now?"

What this small product can do right now?
This is another dubious product or it is ready for use?

As for me, dubious product means any product that has dubious quality of work (and possible contains an endless stream of bugs).

Can I write lint definitions in a DSL (or Dart) that the linter understands?

OK: writing lint rules in english and then implementing the rule as Dart (see https://github.com/dart-lang/linter/blob/master/lib/src/rules/library_prefixes.dart)

AMAZING: writing the rules in a single way (a DSL? Dart code?)

Add a hint when a double is printed

dart2js and vm differ when printing doubles.

  double x = 5.0;
  print("x is $x") ;

vm : 5.0
dart2js : 5

Until Issue dart-lang/sdk#15881 is address, can we give the developer a hint or warning that printing a double results in differing behavior. Giving developers early warnings when code runs differently really helps to shorten the bug cycle.

report a warning for returning a value within a forEach() callback

This issue was originally filed by [email protected]

---

The following code is wrong, but looks right. No warning is reported at compile time and no error happens at runtime:

String findFirstError(Map m) {
  m.forEach((k,v) {
    if (!validate(k,v)) {
      return "found a problem with ${k}";
    }
  });
  return "ok";
}

By analogy with regular for loops this looks like it should return early when it finds the first error, but actually the return value from the callback is ignored, so it always returns "ok".

It seems like we should be able to infer that the callback's return type is void, and therefore any return statements within the callback should not return a value.

Use ";" instead of "{}" for empty constructor bodies

Migrated from dartbug.com/22004:

Instead of:

class Point {
  int x, y;
  Point(this.x, this.y) {}
}

prefer:

class Point {
  int x, y;
  Point(this.x, this.y);
}

Lint for used package not defined in pubspec

Consider another package name? lint? linter? source_lint?

dart_ is a bit redundant.

CC @sethladd for his perspective

Lint configuration source annotations

Ideally, disabling lints will piggyback on a general method to disable warnings via source annotations in the analyzer. Pending resolution there, and perhaps to encourage it, this ticket is meant to kick off the conversation specific to disabling linting (but really about configuring the analyzer in general).

By way of a motivational example, take the following.

class BoxBad {
  var _contents;
  get contents => _contents;
}

which triggers a lint suggesting we should prefer a public final field to a getter in this instance. Suppose, just this once, we'd like to suppress that warning. How would that look?

Some prior art to get the juices flowing.

eslint

/*eslint-disable no-alert, no-console */
alert('foo');
console.log('bar');
/*eslint-enable no-alert */

alert('foo'); // eslint-disable-line

jscs

// jscs:disable requireCurlyBraces
if (x) y(); // all errors from requireCurlyBraces on this line will be ignored
// jscs:enable requireCurlyBraces
if (z) a(); // all errors, including from requireCurlyBraces, on this line will be reported

jshint

/* jshint undef: true, unused: true */

// Code here will be linted with JSHint.
/* jshint ignore:start */
// Code here will be ignored by JSHint.
/* jshint ignore:end */

ignoreThis(); // jshint ignore:line

pylint

# pylint: disable=unused-argument
print self\
    + "foo"

RubyCop:

# rubocop:disable Metrics/LineLength, Style/StringLiterals
[...]

for x in (0..19) # rubocop:disable Style/AvoidFor

stylecop

[SuppressMessage("StyleCop.CSharp.DocumentationRules", "SA1600:ElementsMustBeDocumented", Justification = "Reviewed. Suppression is OK here.")] 
public class MyUndocumentedClass 
{ 
    public void MyUndocumentedMethod 
    { 
    } 
}

tslint

/* tslint:disable */
/* tslint:disable:rule1 rule2 rule3... */ 
[…]

Lint when local variables could be `final`

The style guide says 'PREFER using var without a type annotation for local variables' (https://www.dartlang.org/articles/style-guide/#prefer-using-var-without-a-type-annotation-for-local-variables), which is sufficiently flexible to allow for an additional (per project or similar) rule along the lines of 'PREFER using final for local variables when this does not conflict with its usage'.

The rationale for this is that the explicit final annotation helps programmers thinking clearly about the distinction between variables that simply stand for a value (final ones), and variables whose usage includes mutation (the remaining ones). For a mutated variable, the interplay between the control flow and the assignments to this variable must be taken into account when understanding what it does, or how to correctly modify the explicit occurrences of this variable, or how to correctly modify the control flow; hence, every final in the code simplifies comprehension.

In order to help programmers maintain this discipline, it would be useful to have a lint diagnostic on cases where a variable is never mutated, but still it is not marked as final.

A similar argument could be made for formal parameters in functions/methods, but presumably there is a culture around the treatment of such formals which is so strict that it is acceptable to outlaw mutation at all (and a lint diagnostic is given for all mutations, as proposed in #45).

pubspec: detect two identical keys

I think pubspec-related linting is going to be handled by linter. If so, it could detect cases like this:

name: dart_sample_console
version: 0.0.1
description: A minimal command-line application.
environment:
  sdk: '>=1.0.0 <2.0.0'
dependencies:
  semver: '>=1.0.0 <2.0.0'
  semver: '>=0.1.0 <1.0.0'
dev_dependencies:
  unittest: any

However, I'm not sure how linter is intended to run (on demand, constantly in the background...). In this particular case, it would be useful if the user got instant feedback, as the analysis server provides for .dart files.

Lint for outdated pubspec dependency constraints

One should CONSIDER keeping your dependencies up-to-date to:

• get bug fixes.
• avoid dependency resolution conflicts with other packages that have updated.
• use new features and stop using deprecated features.

This could be a separate tool, e.g. see https://david-dm.org/, but it would be quite similar in purpose and implementation to the other pub lints e.g. #29. For example, many pub lints would be reported on a YamlNode from the pubspec. And a quick fix would edit that node.

den already has functionality to detect and fix outdated dependencies via its CLI, and a dart API will be available soon.

Lint for importing a library from another package's `lib/src` directory.

Anything under lib/src is supposed to be private.

Enhancement for dartanalyzer: Emit hints for special case of function type compatibility checking

The following code does not emit a dartanalyzer error/warning/hint

import 'dart:async';

typedef void VoidReturnType(String msg);

bar(VoidReturnType function, String msg) {
  function(msg);
}

main() {
  Future fun(String m) {
    print(m);
    // The future returned here could come from other parts of the program.
    return new Future.error('unexpected error');
  }

  bar(fun, 'hello world');
}

Reading the dart specification, this seems correct behavior:

A function type (T1, ..., Tk, ...) → T is a subtype of the function type (S1, ..., Sk+j, ...) → S, if all of the following conditions are met:
Either
  S is void,
  or T ⇔ S.

But it can cause easily programming errors, where

• programmer A assumes that the caller will handle the returned Future
• programmer B who does something with the function, assumes it is void

I think this is a case where type systems usually helps users, but not in the case of the dart type system.
It would be very beneficial for our users to get at least a hint in this specific case.

More broadly speaking, it would be beneficial to get hints if a user doesn't act upon a future object it gets from somewhere (neither handles it's value nor it's errors).

No warning given when self-assigment occurs

This issue was originally filed by [email protected]

---

What steps will reproduce the problem?

1. create a class with a member variable: int a
2. create a member method with a parameter: method_x(int a)
3. make an invalid (useless) assignment "a = a;" in that method

What is the expected output? What do you see instead?

I expect to get at least a warning because the code has no effect.
The code that should have been written would be "this.a = a;"

What version of the product are you using? On what operating system?
Dart Editor version 1.0.0_r30187 (DEV)
Dart SDK version 1.0.0.3_r30187
java version "1.7.0_45"
Linux 3.2.0-56-generic #­86-Ubuntu SMP x86_64 GNU/Linux

Please provide any additional information below.

Lint for import "sort order".

Migrated from dartbug/20244:

What steps will clearly show the issue / need for enhancement?

1. Run dartfmt -t on attached foo.dart
2. Observe that imports are not in order.

What is the current output?

import 'package:a_star/a_star_2d.dart';
import 'package:zx/zx.dart';
import 'dart:convert';
import 'dart:async';
import 'package:a_star/a_star.dart';

void main() {
}

What would you like to see instead?

import 'dart:convert';
import 'dart:async';
import 'package:a_star/a_star.dart';
import 'package:a_star/a_star_2d.dart';
import 'package:zx/zx.dart';

void main() {
}

The request, as it stands, is for a transformation supplied by dartfmt. Since dart_style is not in the business of non-WS affecting changes, this feels like linter territory. To start I think we want a lint; ultimately there will be an associated quick fix.

Lint on unnecessary {} in string interpolation (Style Guide - Proposed)

Migrated from dartbug.com/22025:

If the interpolated expression is just a simple identifier (and the string after the interpolation is not alphanumeric), then the {} are not needed. Given:

"Hi, ${name}!"

The linter should suggest:

"Hi, $name!"