proposal: `dart_style_todos`

[HosseinYousefi]

dart_style_todos

Similar to flutter_style_todos but for repos in dart-lang org.

People could not longer be working on a project and taking the original context of the TODO with them. Enforcing to have an accompanying link that explains the issue in full detail helps eliminate this problem.

Links are better than GitHub issue numbers:

• They are clickable from more editors than issue numbers.
• Sometimes the issue is not on GitHub.
• Links survive migrations to the other repos.

Description

Use Dart TODO format: // TODO(https://URL-to-issue): message.

Details

TODOs should include the string TODO in all caps, followed by the link to the respective issue in parenthesis.

Kind

Style

Bad Examples

// TODO: xyz.
// TODO(name): xyz.
// TODO(#123): xyz.

Good Examples

// TODO(https://github.com/dart-lang/linter/issues/123): xyz.

Discussion

dart-lang/native#1522

@devoncarew @mosuem @pq We could add this lint to https://github.com/dart-lang/lints to be consistent everywhere.

[lrhn]

This is not a lint that should be in lints (aka. recommended and core lints). Those apply to every Dart author in the world. Not everyone has the same TODO strategy. Or have issue trackers at all that they can link to.

It's also a problem for the analyzer, when it does adds implementation for unimplemented methods, it also adds

  // TODO: implement <member-name>

That would the trigger the lint. (So, it would need a "TODO: Add URI to this TODO"!)

We could potentially want it in dart-flutter-team-lints, to be consistent inside out own code.
(A lint like this forces a single specific interpretation of "TODO" comments. If that's what a project wants, that's their choice. )

[HosseinYousefi]

This is not a lint that should be in lints (aka. recommended and core lints). Those apply to every Dart author in the world.

Oops, yeah, I didn't mean this. Wrong repo.

We could potentially want it in dart-flutter-team-lints, to be consistent inside out own code.

I meant this -- potentially.

[mosuem]

This is the sort of lint which I would have no problem testing for before submitting code, but would be very annoying while developing code, where the TODOs are more for me personally. I don't know if there is a way of having both these things.

[HosseinYousefi]

This is the sort of lint which I would have no problem testing for before submitting code, but would be very annoying while developing code, where the TODOs are more for me personally. I don't know if there is a way of having both these things.

I use FIXMEs when developing code.

[bwilkerson]

No, we don't currently have any way to specify when a lint should be run (always, before committing, etc.). We also don't have any hooks to allow us to run a lint when you're about to commit some code.