Last time we posted about lints and static analysis and introduced the netglade_analysis package that we use in our projects. Since then, we have even further improved our settings and we’d like to share it with you today.
To recap, we believe that static analysis helps write better, more boring code. It points out otherwise overlooked issues, suggests better and safer methods, removes redundant code, and unifies it across teams and projects. You’ll likely end up with a very strict code, but that’s a good thing. We need the best, clearest code we can get; no questions asked.
Since last time, we added some Dart lints to our package. That alone is a huge benefit, as now we can have Dart 3 specific lints. But the biggest improvement we did was switching to DCM for Teams, a continuation of the Dart Code Metrics plugin.
DCM Teams
DCM Teams (or Individuals for solo developers) is a newer version of DCM. The former version worked only as a Dart Analyzer plugin, while the new For Teams version works as a standalone tool. Removing the plugin’s API dramatically increased the performance. And we feel that; analysis and fixing are now blazingly fast.
Worry not, it also comes with a VSCode extension and IntelliJ plugin, so the experience in an IDE is still familiar. Hinting in editors is extremely quick (maybe even too quick), so you get hints right away when you need them. These extensions also support auto-fixing problems, all problem occurrences, and auto-fixable problems across the file, which is massively useful.
There is also a DCM Discord server where you can ask questions, report issues, or suggest improvements. We posted many issues we found during upgrades on our bigger projects, and they were fixed in the next release. When we tried to suggest some improvements or request a new configuration for a rule, our calls were promptly answered. We commend such an active approach to developing a tool as useful as this.
Another difference is the new licensing model. While the old DCM was available for free, the new one requires a paid license. Thus, maintainers can focus more on improving this amazing tool, so we are glad we can support it this way. And if you’re on the fence, you can always request a trial and try it out.
But DCM is not only a linting-and-fixing tool. While Rules might be the first thing that catches your eye, DCM can do much more. It has Assists to help you while refactoring, Metrics that analyze code maintainability, and Commands that further help you maintain your project.
Rules
We love Rules so much! It’s easily our favorite current DCM feature.
We cannot think of the best rule there is (all of them are awesome), but some of the latest rules like avoid-generics-shadowing, avoid-uncaught-future-errors, avoid-unnecessary-futures, avoid-unnecessary-overrides-in-state, or prefer-dedicated-media-query-methods can make your life a bit better.
We recommend testing the rules an a larger scale project. We did just that, and now we use these DCM settings with explanations for those we disabled.
Assists
DMC also contains Assists, which are basically extensions for your editor that can help you while refactoring. There are only two assists for now, but we believe they can be added if you have an idea for something useful. Assist “wrap with …” helps you predefine any Widget to be wrapped around a selected one, including settings like properties (child, children), if it’s a list, or on which targets it should work. And assist “Extract class to a new file” is something we have missed a lot in both VSCode and IntelliJ, as it helps you extract a class to its own file, with everything working immediately. We often first develop into one file, and then split the implementation into smaller parts, which is very useful.
Metrics
While Rules help you with code and its syntax, Metrics measure its complexity. There are metrics for functions and classes, but also for files. And they are all configurable. An example would be metric “lines of code,” which measures the number of lines of a function. If your team feels like limiting lines for a function to 50 is the best thing to do, now it’s possible.
We still have to review metrics and consider which ones make sense for our case, so we cannot give you our applied knowledge. As always, give it a try.
Commands
For stuff that suits better to “run it on demand” style, there are Commands. There are the obvious ones like init, analyze, fix, and format, but also commands like calculate-metrics to measure the complexity of your code using Metrics. There are check-exports-completeness to check that all public API types are exported and check-unnecessary-nullable to check unnecessary nullable parameters. Then there are commands to check unused stuff check-unused-files, check-unused-l10n, and check-unused-code. And last but not least, check-dependencies for checking if you actually use your dependencies.
We asked the founder himself, Dmitry Zhifarsky, to shed some light on the present and future of DCM:
