How to get the most value from Dart static analysis

The latest version of the 'default' google analyser settings emit the warning:

Omit type annotations for local variables (omit_local_variables_types).

In many cases this improves the readability of code by removing redundant information.

e.g.

var  i = 1;

The removal of the type (int) here doesn't affect the codes readability as the type of i is obvious.

There are however many cases where removing the type actually makes the code harder to read and for a human to do static analysis.

e.g.

    var code = _extractCode(monetaryAmount, codeLength);

There is no information on this line that tells a reader what type 'code' is. The lack of type information forces the reader to stop and check what type _extractCode returns.

If you are analysing a class of some complexity, having to stop and check the type of numerous variables significantly slows down the process.

In a world of auto completion the reduction of a type to 'var' provides little reduction in typing.

The only other argument for reducing a type to 'var' is visual clutter. Reduction in visual clutter should focus on removing redundant information, in the examples given the information being removed is not redundant.

I would suggest that the Omit type annotations warning should only be emitted when it is obvious what the type is.

Now that a Dart team-recommended set of lint rules has been published, I think it makes sense to think of pedantic as the layer on top of those rules which we value highly internally.

(I know that that is not the actual situation; the pedantic rules are just completely separate, but in terms of analysis options files for users, I think it would be pragmatic to think of pedantic this way.)

Only one analysis options file can be included into another; you cannot include a list of analysis options files. Perhaps you can some day, but there is some hashing out w.r.t. merging that needs doing, and it might not be a high priority item. In the meantime, the only way to include multiple analysis options files into your own is by daisy chaining them. package:lints/recommended.yaml includes package:lints/core.yaml, so you get the lint rules from each.

It would be great for pedantic to provide a new analysis options file which includes package:lints/recommended.yaml. Something like package:pedantic/recommended.yaml. WDYT?

future.unawaited vs. unawaited(future) is a matter of taste :) . Both could silent unawaited_futures. What do you think of adding the following extension?

extension FutureExt<T> on Future<T> {
  void get unawaited {}
}

~I am not sure what the unawaited_futures lint would do with a Future? type. If it triggers we may want to allow Future<void>? as the argument here.~

I went ahead and made the api nullable, at least with the current lint implementation it does trigger and I think it makes sense to.

I also added an example since I needed to do that to test the lint behavior anyways.

I've seen CIs for several projects break after the release of the latest package:pedantic - v1.6.0.

In the readme for this project, I see:

This example uses a pinned version because every added lint rule could break a build for projects using it.

You might consider either

• making this more explicit - only recommend that consumers use specific versions, or pin to narrow ranges (>=1.5.0 <1.6.0).
• or, only make pedantic more restrictive - adding more rules - on upgrades to major versions. That would allow projects to use deps like ^1.0.0 and adjust to new versions of pedantic at a more leisurely pace. That would probably also follow the guidance of semver more closely.

Because every version of flutter_test from sdk depends on pedantic 1.8.0+1 and beyond depends on pedantic ^1.9.0, flutter_test from sdk is forbidden.

So, because beyond depends on flutter_test any from sdk, version solving failed.
pub get failed (1; So, because beyond depends on flutter_test any from sdk, version solving failed.

Is this intentional? We need to wait until the Flutter test SDK uses 1.9.0 before we can use it in our projects?

Use a 2.12.0 lower bound since pub does not understand allowed experiments for earlier versions.

Use a 3.0.0 upper bound to avoid a warning in pub and to give some flexibility in publishing for stable.

I just recently hit a snag using unawaited that I believe could have been avoided were it generic.

Thoughts? Reservations?

/cc @davidmorgan @bwilkerson

The unawaited check doesn't flag calls to async methods which return plain void rather than Future<void>, ie:

void main() async {
  try {
    doThing(); // No unawaited error here
  } catch (e) {
    print("caught $e");
  }
}

// Returns void instead of Future<void>
void doThing() async {
  await Future.delayed(Duration(seconds: 1));
  throw Exception("oops");
}

I'm not really clear on the semantics of returning void instead of Future from doThing(). IIRC the compiler used to always require returning a Future from async methods and at some point changed to allow just void, but that still seems to function as an awaitable future.

In the example above, awaiting doThing() results in the exception being caught while not awaiting does not.

Seems like this should be flagged?

const ValueSlider(
      {Key key,
      @required this.onChanged,
      @required this.labels,
      @required this.values,
      @required this.type,
      this.status = AttendanceStatus.none})
      : super(key: key);

this is caught by the linter even though Flutter puts Key first by default.

Vague title, but I couldn't resist it sorry.

Here's my situation: I want to use pedantic but I've also got quite a few extra lints that I want enabled. Some of those will almost certainly be included in pedantic itself at some point. Since the point of pedantic is to adhere to Google's standard, the lints I add are useful as a point of difference. However, nothing guarantees that they are a point of difference.

What's the guidance in this situation? It would be nice to know that if my lint configuration becomes redundant at some point (due to a newer pedantic release) that I would be notified, but it seems that this is not the case (I just tried adding a lint that pedantic has already enabled). Is my only recourse to manually pick through the lints I have enabled and see whether they're redundant? Seems finicky.