Keep your codebase in good shape

Clean up with little effort

As the amount of code and experimental features continues to grow, it becomes increasingly difficult to keep track of things that are no longer used, but you still end up maintaining them and their tests. Not with DCM.

Plus, removing code is awesome, isn't it?

From CLI

Use the check-unused-code command to get a list of the unused declarations and declarations that are used only in your tests.

Or in your IDE (Beta)

Additionally, you can enable the unused code IDE integration to get warnings about both existing and newly created publicly available unused code.

With different modes

By default, this command analyzes all code, even if it's part a package's public API. With exclude-public-api you can exclude such code to avoid any potential breaking changes.

There is another mode that includes class hierarchy into the unused code analysis. It's currently in Beta and is disabled by default as there can be false positives.

And output formats

Use a CLI option to change the output format of the check-unused-code command to be one of the following: plain text, Code Climate, JSON, GitLab, Checkstyle.

For publicly available code

Unused code check works for public and private declarations, including classes, fields, methods, getters, setters, extensions, type aliases, mixins, and enums.

And your image assets

With image assets, it can be really hard to know which assets are actually being used. If you rely on the "flutter_gen" package to generate image assets, DCM will help you quickly spot unused assets, even if the generated files are excluded from the analysis.

Throw away entire files? Why not.

Refactoring may result in unused files or files that are only used in tests. Use unused files detection to find unused files as soon as they appear.

From CLI

Use the check-unused-files command to get a list of the unused files.

Or in your IDE (Beta)

Additionally, you can enable the unused files IDE integration to get warnings about both existing and newly created unused files or files only referenced in tests.

With automatic removal

When called from the CLI, you can pass an additional flag to automatically remove unused files.

And different output formats

Use a CLI option to change the output format of the check-unused-files command to be one of the following: plain text, Code Climate, JSON, GitLab, Checkstyle.

Simplify the inputs of your functions

Parameters play a key role in defining how different parts of your codebase interact with each other, but how many of them can be simplified? What if some of them are unnecessary nullable? Or have an unnecessary default value? And other are either always passed (and can be made non-optional) or are actually never get a value? Use parameter issues detection to quickly find and fix such problems.

With different modes

This check excludes package's public API to avoid potential breaking changes. With monorepo mode, you can disable this behavior and analyze all your code.

Additionally, detection of each issue type can be enabled or disabled separately, giving you enough flexibility to keep only the relevant checks.

And different output formats

Use a CLI option to change the output format of the check-parameters command to be one of the following: plain text, Code Climate, JSON, GitLab, Checkstyle.

Reduce your app bundle

Unused localization means more work for your localization team (or higher costs for a tool to store the localization strings) and is rarely thrown away by the compiler and ends up in your application bundle.

For different approaches

Whether you created Dart files manually or auto-generated them to load and use the localization strings, this check will help you. And with a special CLI flag, you can configure which classes the check should look for.

With different output formats

Use a CLI option to change the output format of the check-unused-l10n command to be one of the following: plain text, Code Climate, JSON, GitLab, Checkstyle.

Timely remove unused external packages

Unused dependencies can introduce version conflicts, which usually result in wasted hours of time. Additionally, dependencies can be accidentally installed into the wrong flavor (or require a flavors update after refactoring) which can later lead to compilation errors or larger bundles.

With configurable excludes

When it comes to dev dependencies, some package can be used transitively without a direct reference in code. To resolve such cases, you can configure this check to exclude a particular package.

And different output formats

Use a CLI option to change the output format of the check-dependencies command to be one of the following: plain text, Code Climate, JSON, GitLab, Checkstyle.

Easily find unwanted duplications

Unwanted duplication can not only lead to differences in behavior when only one of the duplicate declarations changes, but it also means writing and maintaining unnecessary additional tests. Use this check to always be aware of duplication in your codebase.

Resistant to insignificant changes

This check performs a structural comparison and is resistant to insignificant code changes. For example, it ignores changes to declaration names, local variable names, and parameter names.

For implementation and tests

Duplicate code can appear not only in your production code, but also in your tests. This check highlights all completely duplicate test cases, ensuring that all your tests are useful.

With different modes

Since not all code duplication is bad, this check includes flexible configuration options to help filter out expected duplication. You can configure the number of statements after which a declaration is considered a duplicate, hide overridden declarations, or compare declarations only on per-package level.

And different output formats

Use a CLI option to change the output format of the check-code-duplication command to be one of the following: plain text, Code Climate, JSON, GitLab, Checkstyle.