leancodepl / leancodepl/flutter_corelibrary

Enforce actionable and trackable `TODO` comments

Open
#215 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement p: leancode_lint
Dominant language
Dart
Stars
89
Forks
12
Avg merge
2d 7h
Merged PRs (30d)
2

Description

In Patrol, I have accumulated many TODO comments, and I'm not happy with their quality. I would like to be able enforce "good TODOs" - TODOs that have a link to a GitHub issue so the team doesn't lose track of them.

Examples

BAD

// TODO: set reasonable duration or create new exception for this case
// TODO(bartekpacia): set reasonable duration or create new exception for this case
// TODO(bartekpacia): set reasonable duration or create new exception for this case. See #2137

The last is wrong because it makes no sense to include username in the TODO since the person responsible for the issue will very likely be the author of the issue.

GOOD

// TODO: set reasonable duration or create new exception for this case. See https://github.com/leancodepl/patrol/issues/2137

or we could go full-minimalism style - just require the issue number:

// TODO: set reasonable duration or create new exception for this case. See #2137

To paraphrase:

  • GOAL: Enforce every TODO comment to have See #<github-issue-number at the end
  • GOAL: Enforce every TODO comment to not have username (e.g. `// TODO(bartekpacia): ...)
  • NON GOAL: Check if the provided issue link/number is valid/exists/is really an issue (and not a PR or a discussion)
Question

I'm not sure how multiline TODOs should be treated. Should it be:

// TODO(bartekpacia): set reasonable duration or create new exception for this case
// See https://github.com/leancodepl/patrol/issues/2137

or:

// TODO(bartekpacia): set reasonable duration or create new exception for this case
// TODO(bartekpacia): See https://github.com/leancodepl/patrol/issues/2137

?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the TODO examples and the stated GOAL and NON GOAL requirements. Decide how multiline TODOs should be treated, then identify the project's existing TODO enforcement entry point; done means the rules reject usernames and require an issue number or link without validating that the referenced issue exists.

Written by the indexing model from the issue text.

Assessment

Tech stack
dart, flutter
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.