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
:
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
This configuration is used by both CLI and the analysis server.
Basic config example:
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
You can find a list of recommended rules here.
Basic config with metrics:
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
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.