Lint Rules in Flutter
To ‘Flutter’ better, follow the rules.
I Simply by chance, I came upon Tomek Polański’s gist entry called, Strict Flutter lint rules. Many of you will be familiar with Tomek Polański as he has long been a contributing writer to the Flutter community on Medium.com. One of his more famous articles being the ‘cheat sheet’ for Flutter Layouts:
Well, I’m glad I came upon this gist entry. It made me a better programmer. It allows me to better conform my code to the Effective Dart: Style guidelines and then some. It allows for more efficient, and more optimized code. In this article, I’ll show you how to use Polański’s list of Lint rules as well. You should.
I Like Screenshots. Click For Gists.
As always, I prefer using screenshots in my articles over gists to show concepts rather than just show code. I find them easier to work with frankly. However, you can click or tap on these screenshots to see the code in a gist or in Github. Further, it’s better to read this article about mobile development on your computer than on your phone. Besides, we program on our computers — not on our phones. Not yet anyway.
No Moving Pictures, No Social Media
There will be gif files in this article demonstrating aspects of the topic at hand. However, it’s said viewing such gif files is not possible when reading this article on platforms like Instagram, Facebook, etc. They may come out as static pictures or simply blank placeholder boxes. Please, be aware of this and maybe read this article on medium.com
Let’s begin.
Placing Polański’s analysis options file, analysis_options.yaml, with its list of Lint rules at the root of your Flutter project — in the same directory as the file, pubspec.yaml, the Linter analysis tool bundled with the Dart SDK will then highlight suggested modifications to your code to better conform to standard guidelines. Below is a screenshot of the start of his file, but with this one extra line commented out at the start:
Google’s Rules
That line references a list of Lint rules that Google uses in its own Dart code. It’s made available to you using the Pedantic package. If you don’t wish to be ‘as strict’ as those in Polański’s list of rules, I’d suggested you, at least, use Google’s default rules. Comment out the wholeanalysis_options.yaml file, but then introduce that first line to use those rules instead. You should use something. It’ll make you a better Flutter developer. Trust me.
Note, like any Dart package, you must take in the pedantic package into your project as a dev dependency in your pubspec.yaml file so to use it:
However, if you also want to use the one lone function, unawaited(), found inside the pedantic package, you would declare it as a normal dependency:
In my projects, the function, unawaited(), tells the code analyzer that a future is intentionally not to be `waited` on. For example, if this function was not used in the code below, the Linter would warn me the function, saveFirebase(), needs the keyword, await. There are times it need not wait.
Other Rules
Note, there are additional predefined Lint rulesets available to you to use:
- effective_dart for rules corresponding to the Effective Dart style guide.
- flutter for rules used in
flutter analyze
Effective Yet Kinder
Effective Dart is even less strict than Pedantic. Below are some important examples. All are instead acknowledged in Polański’s list.
- Unlike Effective Dart, Pedantic wants to see the use of
@overridewhen appropriate indicating explicitly when things are overridden. - Unlike Pedantic, Effective doesn’t complain if you don’t include the type for local variables.
- Effective Dart says nothing about single vs double quotes while Pedantic prefers single quotes.
- Effective Dart only says to consider using the new function syntax while Pedantic recommends it outright (
void save(bool Function() saveFunc)).
Let Rules Rule
In my case, I’ve commented-out that first line in my analysis_options.yaml file so as to use Polański’s list of rules. You see, the pedantic list doesn’t include some Lint rules and I deemed useful either. Those are listed here, Unused Lint Rules.
The Syntax Of Rules
The rules are listed in the file using the YAML list syntax. However, they could be also listed using the YAML key-value syntax. You’re free to use either syntax, but they can’t be mixed together. Below is the same list of rules each in one syntax and then in the other.
Let Rules Rule Or Not
If in your project, you’ve Dart files you wish not to analyze, you can exclude those files using the exclude: header. You can explicitly list those files or use wildcards to exclude whole sets of files from analysis.
Some Of My Favourite Rules
To end off this article, here are a handful of rules I’m following. I feel following them attributes to better readability and upholds the declarative characteristics of Flutter for better performance. Take them as you wish.
Follow Some Rules
I’d recommend you have your own analysis_options.yamlfile in your projects and follow some set of Lint rules— particularly if you’re starting out in Flutter. I wish I had. I feel it would have helped with the learning curve. ‘Better late than never’, I say. The result regardless is a better Flutter developer, a better understanding of Flutter, and better Flutter apps.
Cheers.
Follow Flutter Community on Twitter: https://www.twitter.com/FlutterComm
