Beginning Flutter Debugging

There are various ways to minimize bugs in your apps. Some of them are: understanding the task you’re about to implement, having a clear Development Process, writing Automated Tests and using Development Tools.

Now, speaking of development tools, we’ve used stuffs like the dart devtools to debug some problems. Another tool we have at our disposal is the Dart Analyzer. This comes integrated to our development environment when you setup Flutter. It is a tool that helps perform static analysis in your codebase.

Now, static analysis allows you debug and examing your source code automatically to check for errors and also if your code conforms to some rules and style guideline. And this is done before the program is executed.

These rules are called lints. Lints are generally used in development to ensure we follow good coding practices. And to check for lints you need a linter and the Dart Analyzer tools comes with the Dart Linter tool built right into it.

Dart analyzer is already activated in our IDE but can be customized to further suite your development needs. This could include adding or removing rules to the default ones. To customize the behaviour of the analyzer, you use the analysis_options.yaml file.

Since Flutter 2.5, you dont need to create this file manually. The analysis_options.yaml file is included in the starter project generated with the flutter create command. It makes use of the Flutter lints package which includes a recommened set of lints to ensure good coding practices.

So in a nutshell, you dont have to do anything extra unless you realy need to. In this course, the sample project we’ve been working with already comes with a custom analysis_options.yaml file. It contains the rules and settings which we use here at raywendelich.com. Let’s see what it looks like.

Inside VSCode, open up the analysis_options.yaml file which is contained in the root folder. This file might look intimidating at first so lets break it down in bits. Let’s scroll to the lint rules. These are the list of rules we set that our code base must follow.

You see rules like always_declare_return_types, prefer_single_quotes and others. Failing to write code that adheres to this rules would generate a warning. Now if you want more than a warning ie you want your code not to run if the code does not adhere to a rule, then you add them to the errors section. The errors section is contained inside analyzer group. This group is responsible for customizing the way the analyzer works.

You can see the missing_required_param is marked as an error. So if you fail to pass in a required parameter to a class then your code would not run. You can see this is useful in preventing possible errors arising from not passing in an expected parameter.

Also we have lines_longer_than_80_chars set to be an error. This was set to make viewing code on the web easier. Like when you want to view sourcecodes on GitHub, having long lines could impact readability. This is a stylistic decision though.

Above the errors sections, we have the strong mode and in here we enabled stict type checking. The first setting prevents the type inference engine from casting varibles declared as dynamic to a more specific data type. While the second setting prevents the type nference engine from making a varible type dynamic when it cant figure out an assigned data type.

With strict type checking, you prevent the analyzer from infering types for you. Finally, we have the exclude section above. It tells the analyzer the files and folder to exclude from static analysis. These could be files like generated files from code runners.

Now to see these settings in action, let’s head over to the main.dart file. There are different severity levels of linter rules. The rule can be a: info, warning and error. The info and warning levels doesn’t cause the analysis to fail while the error level does. The most common ones are info and error levels.

To demonstrate the info rule, we’ll be working with widgets. Widgets are classes and these means we can instantiate it with the new keyword. Let’s add the new keyword before any widget.

Hover on the problems group in the status bar and you can see we have only one problem which is an info. Click on it to open up the problems pane. Our codebase broke the unnecessary_new rule.

Take note of the icon preceding the problem. It shows an icon with i. This is an info rule we broke. We can see possible fixes for this code by clicking on the bulb icon beside the problem. We could remove the unnecessary new keyword or we could ignore this line. Clicking on remove the unnecessary new keyword remove it from that line. Infos mainly has to do with style guides and doesn’t necessarily cause bugs in our code.

Next is the error severity level. Errors are very severe. An example would be providing a try block without a corresponding catch or finally block.

This type of code could cause unexpected outcomes in our app. Let me add a try block:

try{

}

You can see the error and it is underlined with red and denoted with the x icon in the problems tab. And if we try to run the app (run the app), you’ll get a prompt telling you that you have a build error. I’ll remove the try block now.

Now to demonstrate how to ignore rules, let’s work with the prefer_single_quotes rule. I’ll change a single quote sting to double quote. And notice that this is an error so our code wont be able to run.

There are 3 ways we could ignore this rule. We can:ignore the rule for a line, ignore the rule for an entire file, OR ignore the rule for the entire project

First, i’ll ignore the lint for this line by selecting it here. This adds a comment that the dart analyzer understands and it ignores code linting for the line below it. To add more rules, we use commas to separate the them

Now, what if we use double quotes in more than one place? You can see this approach is not very efficient and this leads us the next way of doing this: “Ignore the rule for the entire file”

First, undo your action. Then click on the bulb icon once more then select “Ignore prefer_single_quotes for the entire file”. This add a new line at the top of this file. With this, we can use double quotes anywhere in this file.

The final way which is the best in my opinion is to ignore this rule for the entire project. And we’ll do that by configuring it the dart analyzer setting. Head over to the analysis_options.yaml file. Then update the following code:

analyzer:
  errors:
    prefer_single_quotes: ignore

Here, we set the analyzer to ignore the prefer_single_quotes rule for the entire project. We can also add more rules we wish to ignore here. If you save your work, you’ll see that the error is gone.

Like i mentioned earlier, creating a new Flutter project with the flutter create command generates for you an analysis_options.yaml file that uses the flutter lints package that has been confidured with recommended rules.

With what you’ve covered in this episode, you can have an understanding of what happens under the hood and you can customize the analyzer to suite your development needs.