Guide on Optimizing Flutter App using Dart Analyzer

Flutter projects come equipped with a dart analyzer for static code analysis. When a project is created with Flutter version 2.3.0 and above, a default configuration file named analysis_options.yaml will be generated at the root of the project. Analyzer tool runs checks based on the checks set in this configuration file.

Lints are a set of rules to check the code for potential errors or formatting issues. The configuration file analysis_options.yaml has a set of recommended lints for Flutter applications, packages, and plugins. This is achieved through the automatic inclusion of package:flutter_lints/flutter.yaml.

include: package:flutter_lints/flutter.yaml

linter:
	rules:

Dart-enabled Integrated Development Environments (IDEs) like visual studio code typically display the issues detected by the analyzer in their user interface. Alternatively, you can manually run the analyzer by executing flutter analyze from the terminal to identify and address code issues.

In this blog post, we'll delve into how to customize the lint rules, empowering developers to tailor it to their specific needs.

Customizing Lint Rules in Flutter

The real power of the Dart analyzer configuration lies in the ability to customize lint rules according to your project's requirements. The linter section allows developers to fine-tune lint rules, either by disabling those inherited from flutter.yaml or by enabling additional rules.

Warning: Linter rules may throw false positives.

Configuring Lint rules at the Project level

The analysis_options.yaml configuration file allows developers to customize lint rules at the project level.

linter:
	rules:
    	avoid_print: false  
	    prefer_single_quotes: true 

In this example, the avoid_print rule is disabled by setting it to false, and the prefer_single_quotes rule is enabled by setting it to true. This level of granular control allows developers to enforce or relax specific rules based on their project's coding standards.

Configuring Lint rules at File/code level

In addition to configuring lint rules in the global scope as shown above, developers can suppress lints for specific lines of code or files using comments.

The syntax // ignore: name_of_lint or // ignore_for_file: name_of_lint can be used to silence lint warnings on a case-by-case basis.

// ignore_for_file: name_of_lint
class Class {
  // ignote: name_of_lint
  var _count = 0;

  var _count2 = 0;
}

Sample Case Studies

Now, let us dive into couple of lint rules to get a better idea of what exactly these rules can do.

Omitting explicit Local variable types

In situations where functions tend to be concise, local variables often have limited scope. Omitting the variable type helps shift the reader's focus toward the variable's name and its initialized value, which are often more crucial aspects.

With explicit types

List<List<FoodItem>> findMatchingMeals(Set<FoodItem> kitchen) {
  List<List<FoodItem>> meals = <List<FoodItem>>[];
  for (final List<FoodItem> mealRecipe in recipeBook) {
    if (kitchen.containsAll(mealRecipe)) {
      meals.add(mealRecipe);
    }
  }
  return meals;
}

Without explicit types

List<List<FoodItem>> findMatchingMeals(Set<FoodItem> kitchen) {
  var meals = <List<FoodItem>>[];
  for (final mealRecipe in recipeBook) {
    if (kitchen.containsAll(mealRecipe)) {
      meals.add(mealRecipe);
    }
  }
  return meals;
}

To warn if explicit type is used in the local variables, use the lint rule omit_local_variable_types,

linter:
  rules:
    - omit_local_variable_types

Disable avoid_print in lint rules

It is always advisable to avoid incorporating print statements into production code. Instead, you can opt for debugPrint or enclose print statements within a condition checking for kDebugMode.

void processItem(int itemId) {
  debugPrint('debug: $x');
  ...
}

void processItem(int itemId) {
  if (kDebugMode) {
      print('debug: $x');
  }
  ...
}

By default, print statements are flagged by the analyzer.

With lint rules you can override this, set avoid_print to false as shown below,

linter:
  rules:
	- omit_local_variable_types
	avoid_print: false

Conclusion

Customizing the Dart analyzer is a pivotal step in elevating your Flutter development. Begin by activating recommended lints for Flutter, encouraging good coding practices.

The real power lies in the ability to finely tune lint rules at both project and file levels, granting granular control over code standards. Use comments judiciously to suppress lints where needed.

Lastly, The Dart language provides an extensive list of available lint rules, each documented on the official Dart website https://dart.dev/tools/linter-rules#rules.