rexios_lints 19.0.0

A collection of the linting rules I use for Flutter/Dart projects and packages

These are the linting rules I use for my Flutter and Dart projects

Getting started

Add this package to your dev_dependencies in pubspec.yaml:

dev_dependencies:
  rexios_lints: latest

Goal

The goal of these rules is to enforce code consistency without being annoying. All of the rules in this package were added because of real-life issues I've encountered in projects.

Usage

This package includes four different sets of linting rules. Add the relevant line to the top of your analysis_options.yaml file.

Project:

include: package:rexios_lints/{dart|flutter}/core.yaml

Project with the analyzer plugin enabled:

include: package:rexios_lints/{dart|flutter}/core_extra.yaml

Package:

include: package:rexios_lints/{dart|flutter}/package.yaml

Package with the analyzer plugin enabled:

include: package:rexios_lints/{dart|flutter}/package_extra.yaml

Analyzer plugin

The extra rulesets include an analyzer plugin with custom diagnostics.

Here is an example of how to disable specific diagnostics from the analyzer plugin:

include: package:rexios_lints/dart/package_extra.yaml

plugins:
  rexios_lints:
    diagnostics:
      not_null_assertion: false

Justification

core

always_declare_return_types

• Safety
• Undeclared return types are dynamic. This is almost never intentional. Either declare void or explicitly declare dynamic.

always_use_package_imports

• Readability
• Relative imports make it hard to see where a file is coming from

async_return_with_no_await

• Safety
• Returning a Future from an async function without await skips the function's error handling

avoid_types_on_closure_parameters

• Brevity
• The type checker can inform you of the type if you need to see it

conditional_uri_does_not_exist

• Safety
• Without this rule there is no warning if a conditional import does not exist

document_ignores

• Technical debt
• In the rare case that ignoring a lint rule is unavoidable, the reason should be documented

empty_container_bodies

• Brevity
• Empty class-like declarations can use ; instead of {}

initialize_in_field_declaration

• Readability
• Field initialization is easier to find at the declaration than in a constructor

invalid_runtime_check_with_js_interop_types

• Safety
• Runtime type tests with JS interop types do not work on all platforms

leading_newlines_in_multiline_strings

• Readability
• Not all languages ignore a leading newline in multiline strings. Dart does, and it's more readable. No more remembering if Dart supports it or not.

omit_local_variable_types

• Brevity
• The type checker can inform you of the type if you need to see it

omit_obvious_property_types

• Brevity
• The type checker can inform you of the type if you need to see it

prefer_final_in_for_each

• Safety
• Prevents accidental reassignment

prefer_final_locals

• Safety
• Prevents accidental reassignment

prefer_int_literals

• Brevity
• Integer literals are more concise than double literals

prefer_single_quotes

• Consistency
• Enforces consistency with the rest of the Dart ecosystem

simple_directive_paths

• Readability
• Redundant ./ and ../ segments make import, export, and part paths harder to follow

simplify_variable_pattern

• Brevity
• String(:var length) is more concise than String(length: var length)

switch_on_type

• Safety
• Switching on Type is not type-safe and can lead to bugs if the class hierarchy changes. Prefer to use pattern matching on the variable instead.

unawaited_futures

• Safety
• Ensures that async calls in async methods aren't accidentally ignored

unnecessary_async

• Brevity
• It's easy to end up with unnecessary async modifiers when refactoring

unnecessary_breaks

• Brevity
• Switch cases no longer need explicit break statements as of Dart 3

unnecessary_const_in_enum_constructor

• Brevity
• Generative enum constructors are implicitly const

unnecessary_ignore

• Brevity
• Extra ignore comments are not necessary

unnecessary_lambdas

• Brevity
• Widgets using tear-offs can be declared const in some cases
• This can expose unsafe usage of dynamic types

unnecessary_parenthesis

• Brevity
• It's easy to end up with extra parenthesis when refactoring

unnecessary_primary_constructor_body

• Brevity
• Empty primary constructor bodies can be replaced with ;

unnecessary_type_name_in_constructor

• Brevity
• new is more concise than repeating the type name in constructor declarations

use_declaring_parameters

• Brevity
• Declaring parameters avoid repeating field names and types

use_null_aware_elements

• Brevity
• {?key: "value"} is more concise than {if (key != null) key: "value"}

use_truncating_division

• Brevity
• a ~/ b is more concise than (a / b).toInt()

var_with_no_type_annotation

• Safety
• var on parameters is reserved for declaring parameters. Use an explicit type or omit var.

dart/core

prefer_const_constructors_in_immutables

• Performance
• Const constructors improve performance

flutter/core

migrate_design_widgets

• Technical debt
• package:flutter/material.dart and package:flutter/cupertino.dart are deprecated. Use material_ui and cupertino_ui instead.

prefer_const_constructors

• Performance
• Const constructors improve performance

prefer_const_declarations

• Performance
• Const constructors improve performance

prefer_const_literals_to_create_immutables

• Performance
• Const constructors improve performance

use_colored_box

• Performance
• A ColoredBox is more performant than a Container with a color property

use_decorated_box

• Performance
• A DecoratedBox is more performant than a Container with a decoration property

package

public_member_api_docs

• Enforces documentation. Promotes code readability and maintenance. Also ensures a good documentation score from pana.

extra

do_not_use_raw_paths

• Safety
• Raw path strings (e.g. '/path/to/file') are platform-specific. Use the join method from the path package instead.

do_not_use_stateful_builder

• Best practices
• Usage of StatefulBuilder indicates a complex widget that should be encapsulated in a StatefulWidget class

double_leading_zero

• Readability
• 0.12345 is more readable than .12345

inline_context_lookups

• Performance
• Using many inline context lookups can lead to performance issues

not_null_assertion

• Safety
• Using ! to assert a value is not null is not safe. See the Dart documentation for help.

prefer_async_await

• Readability
• async/await is more readable than Future.then

prefer_immutable_classes

• Performance
• Immutable classes can have const constructors

prefer_timestamps

• Safety
• Creating anything other than UTC timestamps with DateTime.timestamp() or clock.now().toUtc() could lead to storing bad data

unnecessary_container

• Performance
• Container widgets add a lot of overhead. Use specialized widgets when possible.