Let's say there's a new release coming up.
This means there's some cool new features to check out, like Dart super parameters.
You add the
to make sure that you're using the feature consistently.
And now there's squiggly lines all over the place.
Hover over a squiggly line, and a little window pops up.
Your IDE says a quick fix is available.
Click it, and the constructor is automatically converted
to use super parameters.
Amazing!
That's great, but you'll have to go through your entire codebase
and click
That doesn't sound fun.
All of a sudden, Dash, your Flutter godmother, shows up
and whispers in your ear,
"Bibbidi-bobbidi-boo,
here's a tip for you:
run
and watch your code fly."
All of your constructors
have been converted to use super parameters.
But wait, this is Decoding Flutter,
after all.
Let's dive a little deeper into how this works.
The Dart analyzer is a tool that looks at your code
and helps you identify potential problems
without executing a single line,
thanks to static analysis.
The Dart analyzer is a tool
that installs alongside the Dart SDK
and runs in the background whenever you open Dart code in your IDE.
It's the culprit behind all those squiggly lines.
You can also invoke it from the command line via
which many developers wire into their CI/CD pipelines.
You can enable specific lints in the analyzer
by specifying rules within the
while other diagnostics such as compilation errors
are implicitly enabled.
There's three buckets that rules usually fall into:
errors,
style,
and pub.
Error rules help you catch programming errors;
style rules are more about, well, code style--
largely derived from the Dart style guide;
and finally, pub rules,
which involve reading a pubspec
to find issues involving package setup.
Throw all these lints together,
and all of a sudden, you have what seems like
an infinite list of rules to go through.
Luckily, you don't have to pick and choose individual rules.
There's predefined collections of lint rules called "rule sets"
that have been curated by the Dart team.
They're a part of the lints package, which comes with two rule sets:
core and recommended.
Keep in mind, you can add to and disable rules
in these rules sets to your heart's desire.
There's also a
specifically for Flutter projects.
It's automatically included
when you use the Flutter
A quick note to current and future package authors:
There's a lot of packages out there
that currently depend on the Linter package and their pubspec,
but they don't need to.
Packages don't need to depend on the Linter to use lints.
It already comes for free with the Dart SDK.
Now, for the next step in our journey,
the analyzer highlights problems in your code,
so how do you fix it?
You could go through your codebase and fix each error by hand,
but that's no fun.
Luckily, many lint rules come with quick fixes.
These fixes can be automatically applied to your code
with a click of a button or a stroke of a key.
Wherever you see the little squiggly lines in your IDE,
try hovering over it,
and you'll likely get a pop-up window that suggests a quick fix.
Click it, and like magic, the squiggly line is gone
and the problem has been fixed.
If only all of life's problems could be solved like that, huh?
Quick fixes from within the IDE are great
for one-off fixes while you're coding,
but what if you're working with a large codebase
that requires bulk updating?
Just like Dash said,
there's a command line tool for that called
dart fix --dry-run
for your codebase,
and
To see which lint rules have a fix available,
check out the Dart lints page.
All the rules which have a fix available are tagged with "has fix."
Keep in mind, just because a fix exists,
it doesn't mean it will always be applied.
The Analysis Server only applies fixes
when it is certain it won't break anything in your code,
so when it can't be certain,
it still leaves that code for you to fix manually.
Dart fix is a helpful tool for any Dart developers toolbox
because whenever possible,
the Dart and Flutter teams include fixes
with their deprecations and breaking changes.
Wait a minute.
Flutter team?
Yes, the Flutter team!
Flutter takes advantage of what's called "data-driven fixes."
Data-driven fixes allow the Flutter package authors
to provide data about changes
that have been made to the Flutter API
along with instructions
on how to convert usage of an old API to a new one.
This data is then used
to help Flutter users migrate their code
when upgrading to a version of Flutter that has breaking changes
or deprecations.
Hmm. [smacks lips]
Sound familiar?
So how can you apply those data-driven fixes
to your Flutter code?
Take a moment to guess.
If you said using the
or
you're correct.
Next time you experience a breaking change
from upgrading your Flutter version,
save yourself some time and apply the quick fixes.
We've talked about two of Dart's tools in this video:
the Dart analyzer, which finds problems,
and Dart fix, which fixes those problems.
Just like Dart and Flutter,
Dart analyze and Dart fix are better together
at supporting developers with writing and maintaining code.
The time it takes to fix stylistic inconsistencies,
the time it takes to track down some problematic code,
or perhaps the time it takes to manually rewrite
and update some code--
for many of these time-consuming scenarios,
you can add a lint,
ask the analyzer to find issues,
and then use Dart fix to resolve them.
This process lets you make a decision about your code,
add a lint rule,
and never have to think about it ever again.
Dart's tooling aims to give developers one thing:
consistency.
With consistency,
you can spend less time on the things that don't matter
and instead focus on all the things that do matter.
If you'd like to learn more about the Dart analyzer and fixes,
check out the links in the video description.
Hopefully, this helps to save you some time while coding
and lets you take full advantage of Dart
and everything its tooling has to offer.
For more info on Dart and Flutter,
head to
♪ [music] ♪