The original address: flutter – explained. Dev/blog/flutte…

The original author: flutter – explained. / dev/blog author…

Release date: January 4, 2021

One of the best practices we cover in the Flutter Best Practices video is Flutter code analysis and Linting. I’d like to start a small series of different blog posts where we talk about each of these best practices, and today we’re starting with the first one. Code analysis and tips.

Twitter.com/flutter_exp…

www.youtube.com/watch?v=TBg…

Set up code prompt for the Flutter project

First, I would like to say that extra Linting in Flutter is a controversial topic. On the one hand, many people like code hints because they enable us to focus on key parts of the code. However, some people don’t like it because it limits them and leads to faulty build errors. But before we get started, let’s talk about what code hints are and how we can use them to their fullest potential.

Code hints are a way to automatically verify that your code is correct. In our daily work, there is always a lint that we all use. In editors like VSCode and Android Studio, we get errors when our code doesn’t work. Building error visualizations is already a feature of our Linter. This integrated Code Linter is a tool to check if your Code has build problems, which means you can’t even run your application. We don’t have to look for bugs in our code, and when everything works, we know our code is executable.

Thanks to modern tools, we can extend these rules and examine our current projects, not just broken code. For example, we can tell our Linter that we want to check for bad code styles. In Dart and Flutter, additional Lint rules are managed by a file called Analysis_options.yaml. If you haven’t heard of the YAML file extension, it’s just a convenient way to structure a file that allows you to create a tree structure with two Spaces. Please feel free to read more about.yaml file extensions here.

Our mission. Enforce single quotes in our project

Let’s assume that we force all developers to work on our project, and that every string should be finished in single quotes. Our IDE should display immediately, as shown in the image below.

Our sample results

In order for Dart and Flutter’s static code profilers to recognize this error, we had to create an Analysis_options. yaml, which is responsible for providing the Dart profilers instructions for the entire project, running in the background and validating our code. We can create analysis_Options at the root of our project, and most ides like Android Studio or Visual Studio Code will immediately understand what it needs to do. Now, let’s take a closer look at the Analysis_Options file. In analysis_Options, we can modify the behavior of the analyzer and linter.

Analyzers and gaskets

The first part of the usual analysis_options.yaml file is usually the parser. Here we can configure more on how to check the general part of our code. First, we can set whether we want to display errors, warnings, or information as a specific rule. Second, we can exclude files and folders from the inspection system. In addition, we can ignore specific rules. Last but not least, we have the opportunity to introduce additional rigorous type checking and experimental behavior such as no slow check or super mixer.

Now to use the main information we registered with the profiler, we must specify the rules we want to apply in our project. Therefore, we use the Linter part of analysis_options.yaml. In the Linter section, we define which rules will apply to our project. There are about 180 rules that you can specify and make instantly visible in your application. All of the rules would take up space in this blog post if explained, so feel free to check the Linter for Dart website for a list of hint rules you can specify.

Polish rules

As I write this, there are three different categories of hint rules. The first are error rules, which are possible coding errors. Second, we have style rules that define code style matters, such as single or double quotes. It doesn’t tell you if your code is stable, but it helps align the entire code base. Pub rules follow both of these points. This set of rules defines how a PUB package must behave; It contains only two rules, namely how to name packages and sort dependencies in your pubspec.yaml.

avoid_init_to_null

As the name indicates, with the Lint rule, you are no longer allowed to initialize a variable with NULL. But why does this help? In Dart, every variable that does not specify a value is automatically set to NULL. There is no concept of empty memory, or any other traps we might fall into. With this in mind, declaring a variable null in particular would simply make our code bloated and unnecessary.

When explicitly declared null, Linter displays a message

use_string_buffers

Another wonderful rule that many developers don’t really realize is that it is a way to concatenate strings for higher performance. String buffers can help you improve string concatenation and allow you to concatenate in the most efficient way possible. To ensure that all contributors in your code concatenate strings efficiently, we can set the use_string_buffers style rule.

If you can use a StringBuffer, Linter will display a warning

StringBuffer provides a high-performance way to manipulate strings

prefer_double_quotes

The preferred double quote rule allows you to control the specific quote style you want to implement. In our code base, we prefer double quotes, but there is also a single quote rule that allows us to enforce quote styles. This is especially helpful if you work in a multilingual team, as the keyboard layout varies from country to country. In Contrast, in English and American countries, single quotation marks are easier to use, and in other countries, such as Germany, double quotation marks are generally preferred. This rule makes it clear how the maintainer or package or project owner wants to work in general.

The rule favoring double quotes leads to information about the use of double quotes

This is the same rule we used to solve our problem and enforce the use of double quotes throughout the project.

The solution

Ok, now that we know how Linter and Analyzer work, let’s address the goal of this blog post. We’re going to force every developer working on our code base to like double quotes, and if they don’t, we’re going to actually show it as an error. The first thing we need to do is define the parser in terms of the correct severity of the problem. In our case, this would be “wrong”. Next, we define the linter for the new rule we want to add in pubspec.yaml.

Parsers and threads

Now, after we specify the rules and the severity of the execution, we can already see errors in the IDE.

Error message after setting the correct rule

If we run Dart Analyze at the end of the project now, we receive a complete analysis report. Now we can use this command in our terminal. If we use this command in the CI/CD chain now, the build will fail and our team will have to fix it to incorporate into our project.

Lint rule as a package

As always, there are magic packages with predefined rule selection that make it easier to set the first baseline you want to use in your project. Let’s start by looking at how to include them in our project.

Install a third-party hint rule set

To add a set of rating rules, we must first add a dependency on the pub.dev package in pubspec.yaml. For example, we want to add the Lint package to our project.

Add Lint to our dev dependency

The next step is to import the rules from the package into our analysis_options.yaml.

Add the Analysis_Options of the Lint package to the Analysis_Options of our project

As soon as you open the different files now, you will find that the linting rules of the package have been taken into account and can be used. Let’s say you don’t like a rule. You can easily override this behavior by including linents and parsers. Your rules will override the package’s rules so that you can always control the content of the prompts.

A complete solution to override specific rules

Polish package

Lint package flag

Pascal Welsch created the first Lint package, which included baselines for Lint rules for the Flutter and Dart projects. If you use this package, you can extend or exclude rules after the fact, but it’s created with consumers. This means that if you don’t necessarily work on the Flutter project. This should be your approach.

Pedantic

The second package I want to introduce you to is the so-called Pedantic package. The Flutter team created bypass packages to support a set of rules that are often more restrictive in terms of usage and allowable, and are sometimes a little over-engineered.

conclusion

In this article, we learned how to use Linting rules to our advantage and enforce the rules so that every developer we work with works the same way. Generating these rules and discussing them in a team can be tedious, and many would say it’s not worth it. But if you start the conversation and discussion now, you have the right tools to join the discussion and give some valuable insights.

Thanks for reading, and let me know what you think of Linting’s rule in the description below!

www.deepl.com translation