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

[pq]

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.

[seaneagan]

Until dart gets union types, I think there will be a lot of false positives with this one.

[pq]

@seaneagan : you may well be right. The interesting thing will be gathering some hard data. You'll notice too that Bob flagged this as PREFER. I'm guessing, in general, those will be hard to get crisp agreement on.

There's also the question of what constitutes privacy. In my case I really dislike using underscores everywhere and have lots of "public" code that is actually private since it never gets exported.

Net-net: turning this on by default (without a bunch of fine tuning or configurability) will be contentious for sure!

[pq]

Conversation related to what constitutes public API from dartdoc's perspective over here: dart-lang/dartdoc#284.

[pq]

Updated text with new reference to effective dart.

[pq]

Implemented w/ 4b2af08.