Skip to main content

Choosing Your First DCM Rules

Given that DCM includes more than 400 lint rules, choosing your first set of rules can be a tedious task.

This guide will walk you through various techniques that will help you simplify this process.

The "recommended" preset is a curated set of rules that focuses on potential bugs and memory leaks and currently includes around 150 rules.

It is also a special preset that is bundled with the tool and does not require the installation of any additional packages.

To enable it, simply update your analysis_options.yaml file:

analysis_options.yaml
dart_code_metrics:
  extends:
    - recommended

Based on Used Packages​

Since DCM includes rules not only for Flutter and Dart but also for various packages such as bloc, provider, and riverpod, enabling rules for the package you use can be a good start.

To find package-specific rules, go to the rules page and use the "Categories" filter. All supported packages will be listed there.

Closing Obvious Pain Points​

Another great approach to choosing your first set of DCM rules is when you already have a list of pain points that you'd like to address.

For example, your team often has to deal with null reference exceptions that come from the non-null assertion (or bang) operator ! (avoid-non-null-assertion can help here). Or with exceptions from incorrect type casts.

void fn(String? nullable) {
  // LINT: Avoid non-null assertions. Try rewriting the code without it.
  nullable!.split(...);
}

Or, you have your own design system and would like to prevent the team from using the build-in Flutter widgets instead of your own widgets (banned-usage can greatly help with that, plus it has a very flexible configuration).

class _MyState extends State<MyWidget> {
  Widget build(BuildContext context) {
    // LINT: Avoid using MaterialButton. Use OurCustomButton instead.
    return MaterialButton(...);
  }
}

To quickly find rules for a particular group of issues, use tags. For example, choosing the nullability tag will show all related rules (including the avoid-non-null-assertion mentioned above). Additionally, each rule page has a section for "Related Rules" that will help you find even more rules that cover your pain points.

Paying Closer Attention to Code Reviews​

Sometimes the best time to enable a certain rule is after a code review.

When doing code reviews, pay closer attention to what your team members or you ask to be changed/fixed. If your comment is not related to business logic, in most cases, it can be replaced with a lint rule, which will allow the team to no longer focus on that specific issue.

Bonus point: it will also make the code review process faster.

Rules That Can Easily Be Fixed​

Some DCM rules support quick fixes that can be applied via the IDE quick-fix menu or using dcm fix.

To find rules that can be automatically fixed, use the "With fixes" filter on the rules page.

Rules That Have No Violations​

With the help of dcm init preview, you can run selected (or all) DCM rules against your codebase to see how many violations each rule has. Going through a list of rules with 0 violations (meaning you won't need to spend time fixing issues) can be another way to choose your first set of rules.

info

If you are integrating DCM into an existing project, check out this guide to learn about various techniques.

Last updated on