Skip to main content

Configuration

DCM is designed to be flexible and configurable for your use case. You can turn off every rule and run only with enabled metrics calculation or have both rules and metrics enabled.

To configure DCM, add a dart_code_metrics entry to analysis_options.yaml:

analysis_options.yaml
dart_code_metrics:
  extends:
    - ... # configures the list of preset configurations
  formatter:
    - ... # configures the formatter
  assists:
    - ... # configures the list of assists
  metrics:
    - ... # configures the list of reported metrics
  metrics-exclude:
    - ... # configures the list of files that should be ignored by metrics
  pubspec-rules:
    - ... # configures the list of rules for pubspec.yaml
  rules:
    - ... # configures the list of rules
  rules-exclude:
    - ... # configures the list of files that should be ignored by rules
  unused-code-exclude:
    - ... # configures the list of files that should be ignored by unused code checks
note

This configuration is used by both CLI and the analysis server.

Basic config example:

analysis_options.yaml
dart_code_metrics:
  rules:
    - avoid-dynamic
    - avoid-passing-async-when-sync-expected
    - avoid-redundant-async
    - avoid-unnecessary-type-assertions
    - avoid-unnecessary-type-casts
    - avoid-unrelated-type-assertions
    - avoid-unused-parameters
    - avoid-nested-conditional-expressions
    - newline-before-return
    - no-boolean-literal-compare
    - no-empty-block
    - prefer-trailing-comma
    - prefer-conditional-expressions
    - no-equal-then-else
    - prefer-moving-to-variable
    - prefer-match-file-name
    - avoid-collapsible-if
    - avoid-redundant-else
    - avoid-incomplete-copy-with
    - avoid-self-compare
    - avoid-self-assignment
    - avoid-unnecessary-nullable-return-type
    - avoid-unrelated-type-casts
    - prefer-declaring-const-constructor
info

You can find a list of recommended rules here.

Basic config with metrics:

analysis_options.yaml
dart_code_metrics:
  metrics:
    cyclomatic-complexity: 20
    number-of-parameters: 4
    maximum-nesting-level: 5
  metrics-exclude:
    - test/**
  rules:
    - avoid-dynamic
    - avoid-passing-async-when-sync-expected
    - avoid-redundant-async
    - avoid-unnecessary-type-assertions
    - avoid-unnecessary-type-casts
    - avoid-unrelated-type-assertions
    - avoid-unused-parameters
    - avoid-nested-conditional-expressions
    - newline-before-return
    - no-boolean-literal-compare
    - no-empty-block
    - prefer-trailing-comma
    - prefer-conditional-expressions
    - no-equal-then-else
    - prefer-moving-to-variable
    - prefer-match-file-name
    - avoid-collapsible-if
    - avoid-redundant-else
    - avoid-incomplete-copy-with
    - avoid-self-compare
    - avoid-self-assignment
    - avoid-unnecessary-nullable-return-type
    - avoid-unrelated-type-casts
    - prefer-declaring-const-constructor
info

You can find a list of recommended metrics here.

Custom analysis_option files​

Aside from the regular analysis_option.yaml file, you can add a custom config file that matches one of the given patterns

  • starts with analysis_options (e.g. analysis_options.1.1.0.yaml)
  • starts with dcm (e.g. dcm_config.yaml or dcm.yaml)
  • placed inside a folder called dcm (e.g. dcm/config.yaml)

If such a file is referenced by any analysis_option.yaml file, DCM will correctly update configuration changes, validate rule names and display a configuration icon (⚙️) for configurable rules.

However, unlike for regular analysis_options.yaml files, code actions are not available.

Next Steps​