Enhance Your Coding Skills with Flutter Lints
24 min readSep 19, 2023
When you’re part of a big mobile team at a company, every engineer might write code in their way. This can lead to issues, both for the current team and new engineers who join later. To prevent these differences and make things smoother, it’s helpful to have some basic rules for how we write and organize our code. That’s where Linting comes in handy. It helps us follow these rules and keep our code consistent.
What is linting?
A linter, often called “Lint,” is like a helpful assistant for your code. It looks at your program’s instructions and points out mistakes, bugs, style problems, and anything that looks a bit unusual. This is like having a proofreader for your code, making sure it’s easy to read and work on together.
You can use the linter directly in your coding environment (IDE), or you can run it using the “dart analyze” command. Either way, it’s a handy tool to keep your code in tip-top shape.
Types
Each rule belongs to one of the following groups:
Errors: Possible errors or mistakes in your code.
Style: Matters of style, largely derived from the Dart style guide.
Pub: Possible issues with pub package setup.
A quick tip: It’s a smart move to establish your code quality rules right from the start of a project. If you add them later, you might end up with a heap of errors and warnings that can be pretty challenging to sort out. So, getting your lint rules in place early is a good practice to keep things running smoothly.
Let’s add flutter lints:
Check for lib/analysis_options.yaml . New projects will have this file already created. For older projects, you need to create the file manually.
We have two steps:
- Enabling default rules
- Setting and customizing your own Lint rules.
This is a default generated analysis_option.yaml .
# This file configures the analyzer, which statically analyzes Dart code to
# check for errors, warnings, and lints.
#
# The issues identified by the analyzer are surfaced in the UI of Dart-enabled
# IDEs (https://dart.dev/tools#ides-and-editors). The analyzer can also be
# invoked from the command line by running `flutter analyze`.
# The following line activates a set of recommended lints for Flutter apps,
# packages, and plugins designed to encourage good coding practices.
include: package:flutter_lints/flutter.yaml
linter:
# The lint rules applied to this project can be customized in the
# section below to disable rules from the `package:flutter_lints/flutter.yaml`
# included above or to enable additional rules. A list of all available lints
# and their documentation is published at
# https://dart-lang.github.io/linter/lints/index.html.
#
# Instead of disabling a lint rule for the entire project in the
# section below, it can also be suppressed for a single line of code
# or a specific dart file by using the `// ignore: name_of_lint` and
# `// ignore_for_file: name_of_lint` syntax on the line or in the file
# producing the lint.
rules:
# avoid_print: false # Uncomment to disable the `avoid_print` rule
# prefer_single_quotes: true # Uncomment to enable the `prefer_single_quotes` rule
# Additional information about this file can be found at
# https://dart.dev/guides/language/analysis-optionslet’s understand what the script means!
- include: package:flutter_lints/flutter.yaml
activates sets of recommended lints for flutter apps, packages, and plugins. - linter:
rules:
- annotate_overrides
After setting up the linter rules, run the command $ flutter analyze to analyze and check your code.
Real-Life Example in My Project:
- The full analysis options YAML file is:
# This file configures the analyzer, which statically analyzes Dart code to
# check for errors, warnings, and lints.
#
# The issues identified by the analyzer are surfaced in the UI of Dart-enabled
# IDEs (https://dart.dev/tools#ides-and-editors). The analyzer can also be
# invoked from the command line by running `flutter analyze`.
# The following line activates a set of recommended lints for Flutter apps,
# packages, and plugins designed to encourage good coding practices using Passy's lint package
include: package:lint/analysis_options.yaml
# I use specialize analyzer settings to assist in having a
# fine-tuned developer feedback concerning types
# beyond the recommendations as I have found that it saves
# developer time when migrating to the dart major version
# versions.
analyzer:
# required for to ignore auto-generated code as it will always hang using the
# analyzer. DCDG UML generation tool requires this line as it does use the
# analyzer as a dependency.
# per https://github.com/dart-lang/sdk/issues/25551
# I need to use quotes and regex as a work around
exclude:
# exclude intl files
- "**/l10n.dart"
- "**/messages_all.dart"
- "**/messages_en.dart"
# Generated for Flutter web apps. Since it is auto-generated, errors should be ignored
- lib/generated_plugin_registrant.dart
# my modified settings for language and strong-mode and errors which are modified from the defaults that the lint package sets.
language:
strict-raw-types: true
# implicit-casts: false is now default which is why I do not list it in strong mode like underlying lint package does
strong-mode:
implicit-dynamic: false
implicit-casts: false
errors:
missing_required_param: warning
missing_return: warning
todo: ignore
invalid_annotation_target: ignore
# Reassignment should be treated as warning (not a hint)
parameter_assignments: warning
plugins:
- dart_code_metrics
dart_code_metrics:
anti-patterns:
- long-method
- long-parameter-list
metrics:
cyclomatic-complexity: 20
halstead-volume: 150
maximum-nesting-level: 5
number-of-parameters: 4
source-lines-of-code: 50
lines-of-code: 100
maintainability-index: 50
number-of-methods: 10
weight-of-class: 0.33
technical-debt:
threshold: 1
todo-cost: 161
ignore-cost: 320
ignore-for-file-cost: 396
as-dynamic-cost: 322
deprecated-annotations-cost: 37
file-nullsafety-migration-cost: 41
unit-type: "USD"
metrics-exclude:
- "test/**"
# per https://dartcodemetrics.dev/docs/getting-started/configuration#configuring-a-rules-entry
# and https://dartcodemetrics.dev/docs/rules/overview
rules:
# common
- avoid-collection-methods-with-unrelated-types
- avoid-duplicate-exports
- avoid-dynamic
- avoid-global-state
- avoid-ignoring-return-values
- avoid-late-keyword
- avoid-missing-enum-constant-in-map
- avoid-non-ascii-symbols
- avoid-non-null-assertion
- avoid-throw-in-catch-block
- avoid-top-level-memebrs-in-tests
- avoid-unnecessary-type-assertions
- avoid-unnecessary-type-casts
- avoid-unrelated-type-assertions
- avoid-unused-parameters
- binary-expresssion-operand-order
- double-literal-format
- format-comment:
ignored-patterns:
- ^ cSpell.* # Ignores all the comments that start with 'cSpell' (for example: '// cSpell:disable-next-line').
- member-ordering-extended:
order:
- build-method
- init-state-method
- did-change-dependencies-method
- did-update-widget-method
- dispose-method
- newline-before-return
- no-boolean-literal-compare
- no-empty-block
- no-equal-arguments:
ignored-parameters:
- height
- width
- no-equal-then-else
- no-magic-number:
allowed: [3.14, 100, 12]
- no-object-declaration
- prefer-async-await
- prefer-commenting-analyzer-ignores
- prefer-correct-identifier-length:
exceptions: [ 'a' ]
max-identifier-length: 30
min-identifier-length: 4
- prefer-correct-type-name:
excluded: [ 'exampleExclude' ]
min-length: 3
max-length: 40
- prefer-enums-by-name
- prefer-first
- prefer-immediate-return
- prefer-last
- prefer-match-file-name
- prefer-moving-to-variable:
allowed-duplicated-chains: 3
- prefer-trailing-comma:
break-on: 2
- tag-name:
var-names: [_kTag]
strip-prefix: _
strip-postfix: State
# flutter
- always-remove-listener
- avoid-border-all
- avoid-returning-widgets:
ignored-names:
- testFunction
ignored-annotations:
- allowedAnnotation
- avoid-shrink-wrap-in-lists
- avoid-unnecessary-setstate
- avoid-use-expanded-as-spacer
- avoid-wrapping-in-padding
- prefer-const-border-radius
- prefer-correct-edge-insets-constructor
- prefer-extracting-callbacks:
ignored-named-arguments:
- onPressed
allowed-line-count: 3
# intl
- prefer-intl-name
- provide-correct-intl-args
linter:
rules:
# Default Lint Rules turned on by lint package:
# always_declare_return_types
# always_require_non_null_name_parameters
# always_use_package_imports
# annotate_overrides
# avoid_bool_literals_in_conditional_expressions
# avoid_catching_errors
# avoid_classes_with_only_static_members
# avoid_dynamic_calls
# avoid_double_and_int_checks
# avoid_empty_else
# avoid_escaping_inner_quotes
# avoid_field_initializers_in_const_classes
# avoid_final_parameters
# avoid_function_literals_in_foreach_calls
# avoid_implementing_value_types
# avoid_init_to_null
# avoid_multiple_declarations_per_line
# avoid_null_checks_in_equality_operators
# avoid_positional_boolean_parameters
# avoid_print
# avoid_private_typedef_functions
# avoid_redundant_argument_values
# avoid_relative_lib_imports
# avoid_return_types_on_setters
# avoid_returning_null_for_future
# avoid_returning_null_for_void
# avoid_setters_without_getters
# avoid_shadowing_type_parameters
# avoid_single_cascade_in_expression_statements
# avoid_type_to_string
# avoid_types_as_parameter_names
# avoid_unnecessary_containers
# avoid_unused_constructor_parameters
# avoid_void_async
# avoid_web_libraries_in_flutter
# await_only_futures
# camel_case_extensions
# camel_case_types
# cancel_subscriptions
# cast_nullable_to_non_nullable
# conditional_uri_does_not_exist
# constant_identifier_names
# control_flow_in_finally
# curly_braces_in_flow_control_structures
# depend_on_referenced_packages
# deprecated_consistency
# directives_ordering
# empty_catches
# empty_constructor_bodies
# empty_statements
# eol_at_end_of_file
# exhaustive_cases
# file_names
# hash_and_equals
# implementation_imports
# invariant_booleans
# iterable_contains_unrelated_type
# join_return_with_assignment
# leading_newlines_in_multiline_strings
# library_names
# library_prefixes
# list_remove_unrelated_type
# missing_whitespace_between_adjacent_strings
# no_adjacent_strings_in_list
# no_duplicate_case_values
# no_leading_underscores_for_library_prefixes
# no_leading_underscores_for_local_identifiers
# no_logic_in_create_state
# no_runtimeType_toString
# non_constant_identifier_names
# noop_primitive_operations
# null_check_on_nullable_type_parameter
# null_closures
# overridden_fields
# package_names
# package_prefixed_library_names
# parameter_assignments
# prefer_asserts_in_initializer_lists
# prefer_collection_literals
# prefer_conditional_assignment
# prefer_const_constructors
# prefer_const_constructors_in_immutables
# prefer_const_declarations
# prefer_const_literals_to_create_immutables
# prefer_constructors_over_static_methods
# prefer_contains
# prefer_equal_for_default_values
# prefer_final_fields
# prefer_final_in_for_each
# prefer_final_locals
# prefer_for_elements_to_map_fromIterable
# prefer_function_declarations_over_variables
# prefer_generic_function_type_aliases
# prefer_if_elements_to_conditional_expressions
# prefer_if_null_operators
# prefer_initializing_formals
# prefer_inlined_adds
# prefer_interpolation_to_compose_strings
# prefer_is_empty
# prefer_is_not_empty
# prefer_is_not_operator
# prefer_iterable_whereType
# prefer_null_aware_method_calls
# prefer_null_aware_operators
# prefer_spread_collections
# prefer_typing_uninitialized_variables
# prefer_void_to_null
# provide_deprecation_message
# recursive_getters
# require_trailing_commas
# secure_pubspec_urls
# sized_box_for_whitespace
# sized_box_shrink_expand
# slash_for_doc_comments
# sort_child_properties_last
# sort_pub_dependencies
# sort_unnamed_constructors_first
# test_types_in_equals
# throw_in_finally
# tighten_type_of_initializing_formals
# type_annotate_public_apis
# type_init_formals
# unnecessary_await_in_return
# unnecessary_brace_in_string_interps
# unnecessary_const
# unnecessary_getters_setters
# unnecessary_late
# unnecessary_new
# unnecessary_null_aware_assignments
# unnecessary_null_checks
# unnecessary_null_in_if_null_operators
# unnecessary_nullable_for_final_variable_declarations
# unnecessary_overrides
# unnecessary_parenthesis
# unnecessary_raw_strings
# unnecessary_statements
# unnecessary_string_escapes
# unnecessary_string_interpolations
# unnecessary_this
# unrelated_type_equality_checks
# unsafe_html
# use_build_context_synchronously
# use_decorated_box
# use_full_hex_values_for_flutter_colors
# use_function_type_syntax_for_parameters
# use_is_even_rather_than_modulo
# use_named_constants
# use_late_for_private_fields_and_variables
# use_rethrow_when_possible
# use_setters_to_change_properties
# use_string_buffers
# use_test_throws_matchers
# valid_regexps
# void_checks
#
# Rules that are turned off in lint package by default:
# always_put_control_body_on_new_line
# always_put_required_named_parameters_first
# always_specify_types
# avoid_annotating_with_dynamic
# avoid_as
# avoid_catches_without_on_clauses
# avoid_equals_and_hash_code_on_mutable_classes
# avoid_js_rounded_ints
# avoid_renaming_method_parameters
# avoid_returning_null
# avoid_returning_this
# avoid_slow_async_io
# avoid_types_on_closure_parameters
# cascade_invocations
# close_sinks
# comment_references
# do_not_use_environment
# flutter_style_todos
# lines_longer_than_80_chars
# literal_only_boolean_expressions
# omit_local_variable_types
# one_member_abstracts
# only_throw_errors
# package_api_docs
# prefer_adjacent_string_concatenation
# prefer_asserts_with_message
# prefer_double_quotes
# prefer_expression_function_bodies
# prefer_final_parameters
# prefer_foreach
# prefer_int_literals
# prefer_mixin
# prefer_relative_imports
# prefer_single_quotes
# public_member_api_docs
# sort_constructors_first
# unawaited_futures
# unnecessary_final
# unnecessary_lambdas
# use_if_null_to_convert_nulls_to_bools
# use_key_in_widget_constructors
# use_to_and_as_if_applicable
#
# rules auto set by the lint package:
# Prevents accidental return type changes which results in a breaking API change.
# Enforcing return type makes API changes visible in a diff
#
# http://dart-lang.github.io/linter/lints/always_declare_return_types.html
# - always_declare_return_types
# Single line `if`s are fine as recommended in Effective Dart "DO format your code using dartfmt"
#
# http://dart-lang.github.io/linter/lints/always_put_control_body_on_new_line.html
# - always_put_control_body_on_new_line
# Flutter widgets always put a Key as first optional parameter which breaks this rule.
# Also violates other orderings like matching the class fields or alphabetically.
#
# http://dart-lang.github.io/linter/lints/always_declare_return_types.html
# - always_put_required_named_parameters_first
# All non nullable named parameters should be and annotated with @required.
# This allows API consumers to get warnings via lint rather than a crash a runtime.
# Might become obsolete with Non-Nullable types
#
# http://dart-lang.github.io/linter/lints/always_require_non_null_named_parameters.html
# - always_require_non_null_named_parameters
# Always use package: imports.
# While both, relative and package imports are fine, package imports are preferred because they allow for easy find
# and replace
# Conflicting with: prefer_relative_imports, avoid_relative_lib_imports
#
# Dart SDK: >= 2.10.0-10.0.dev • (Linter v0.1.118)
# http://dart-lang.github.io/linter/lints/always_use_package_imports.html
# - always_use_package_imports
# Since dart 2.0 dart is a sound language, specifying types is not required anymore.
# `var foo = 10;` is enough information for the compiler to make foo an int.
# Violates Effective Dart "AVOID type annotating initialized local variables".
# Makes code unnecessarily complex https://github.com/dart-lang/linter/issues/1620
#
# This convention is used in the Flutter repository
#
# Dart SDK: >= 2.0.0 • (Linter v0.1.4)
#
# http://dart-lang.github.io/linter/lints/always_specify_types.html
# - always_specify_types
# Protect against unintentionally overriding superclass members
#
# http://dart-lang.github.io/linter/lints/annotate_overrides.html
# - annotate_overrides
# All methods should define a return type. dynamic is no exception.
# Violates Effective Dart "PREFER annotating with dynamic instead of letting inference fail"
#
# http://dart-lang.github.io/linter/lints/avoid_annotating_with_dynamic.html
# - avoid_annotating_with_dynamic
# A leftover from dart1, should be deprecated
#
# - https://github.com/dart-lang/linter/issues/1401
# http://dart-lang.github.io/linter/lints/avoid_as.html
# - avoid_as
# Highlights boolean expressions which can be simplified
# http://dart-lang.github.io/linter/lints/avoid_bool_literals_in_conditional_expressions.html
#- avoid_bool_literals_in_conditional_expressions
# There are no strong arguments to enable this rule because it is very strict. Catching anything is useful
# and common even if not always the most correct thing to do.
#
# http://dart-lang.github.io/linter/lints/avoid_catches_without_on_clauses.html
# - avoid_catches_without_on_clauses
# Errors aren't for catching but to prevent prior to runtime
#
# http://dart-lang.github.io/linter/lints/avoid_catching_errors.html
#- avoid_catching_errors
# Can usually be replaced with an extension
#
# Dart SDK: >= 2.0.0 • (Linter v0.1.31)
#
# http://dart-lang.github.io/linter/lints/avoid_classes_with_only_static_members.html
- avoid_classes_with_only_static_members
# Never accidentally use dynamic invocations, as it makes type error very hard to find
# Dart SDK: unreleased • (Linter v1.0)
# https://dart-lang.github.io/linter/lints/avoid_dynamic_calls.html
#- avoid_dynamic_calls
# Prevents accidental empty else cases. See samples in documentation
#
# http://dart-lang.github.io/linter/lints/avoid_empty_else.html
#- avoid_empty_else
# It is expected that mutable objects which override hash & equals shouldn't be used as keys for hashmaps.
# This one use case doesn't make all hash & equals implementations for mutable classes bad.
#
# https://dart-lang.github.io/linter/lints/avoid_equals_and_hash_code_on_mutable_classes.html
# - avoid_equals_and_hash_code_on_mutable_classes
# Use different quotes instead of escaping
# Dart SDK: >= 2.8.0-dev.11.0 • (Linter v0.1.111)
# https://dart-lang.github.io/linter/lints/avoid_escaping_inner_quotes.html
#- avoid_escaping_inner_quotes
# Prevents unnecessary allocation of a field
#
# http://dart-lang.github.io/linter/lints/avoid_field_initializers_in_const_classes.html
#- avoid_field_initializers_in_const_classes
# Since lint `parameter_assignments` is enabled, the final parameter doesn't add more safety, it would be just verbose
# Conflicts with prefer_final_parameters
#
# http://dart-lang.github.io/linter/lints/avoid_final_parameters.html
#- avoid_final_parameters
# Prevents allocating a lambda and allows return/break/continue control flow statements inside the loop
#
# Dart SDK: >= 2.0.0 • (Linter v0.1.30)
#
# http://dart-lang.github.io/linter/lints/avoid_function_literals_in_foreach_calls.html
#- avoid_function_literals_in_foreach_calls
# Don't break value types by implementing them
# http://dart-lang.github.io/linter/lints/avoid_implementing_value_types.html
#- avoid_implementing_value_types
# Removes redundant `= null;`
# https://dart-lang.github.io/linter/lints/avoid_init_to_null.html
#- avoid_init_to_null
# Only useful when targeting JS
# Warns about too large integers when compiling to JS
#
# https://dart-lang.github.io/linter/lints/avoid_js_rounded_ints.html
# - avoid_js_rounded_ints
# Not useful for coding golf, but in every environment where code is maintained by multiple authors.
#
# Dart SDK: 2.13.0 • (Linter v1.1.0)
#
# https://dart-lang.github.io/linter/lints/avoid_multiple_declarations_per_line.html
#- avoid_multiple_declarations_per_line
# Null checks aren't required in ==() operators
#
# https://dart-lang.github.io/linter/lints/avoid_null_checks_in_equality_operators.html
#- avoid_null_checks_in_equality_operators
# Good APIs don't use ambiguous boolean parameters. Instead use named parameters
# https://dart-lang.github.io/linter/lints/avoid_positional_boolean_parameters.html
#- avoid_positional_boolean_parameters
# Don't call print in production code
#
# https://dart-lang.github.io/linter/lints/avoid_print.html
#- avoid_print
# Always prefer function references over typedefs.
# Jumping twice in code to see the signature of a lambda sucks. This is different from the flutter analysis_options
# https://dart-lang.github.io/linter/lints/avoid_private_typedef_functions.html
#- avoid_private_typedef_functions
# Don't explicitly set defaults
# Dart SDK: >= 2.8.0-dev.1.0 • (Linter v0.1.107)
# https://dart-lang.github.io/linter/lints/avoid_redundant_argument_values.html
#- avoid_redundant_argument_values
# package or relative? Let's end the discussion and use package everywhere.
#
# https://dart-lang.github.io/linter/lints/avoid_relative_lib_imports.html
#- avoid_relative_lib_imports
# It's definitely not recommended to break dartdoc but besides that there is no reason to inherit a bad named parameter
# https://dart-lang.github.io/linter/lints/avoid_renaming_method_parameters.html
# - avoid_renaming_method_parameters
# Setters always return void, therefore defining void is redundant
#
# https://dart-lang.github.io/linter/lints/avoid_return_types_on_setters.html
#- avoid_return_types_on_setters
# Since nullsafety landed in dart, `int?` is completely fine to return null and `int` can't return `null` at all.
#
# In general there are plenty of valid reasons to return `null`, not a useful rule
#
# Dart SDK: >= 2.0.0 • (Linter v0.1.31)
#
# https://dart-lang.github.io/linter/lints/avoid_returning_null.html
# - avoid_returning_null
# Don't use `Future?`, therefore never return null instead of a Future.
# Will become obsolete one Non-Nullable types land
# https://dart-lang.github.io/linter/lints/avoid_returning_null_for_future.html
#- avoid_returning_null_for_future
# Use empty returns, don't show off with you knowledge about dart internals.
# https://dart-lang.github.io/linter/lints/avoid_returning_null_for_void.html
#- avoid_returning_null_for_void
# Hinting you forgot about the cascade operator. But too often you did this on purpose.
# There are plenty of valid reasons to return this.
#
# https://dart-lang.github.io/linter/lints/avoid_returning_this.html
# - avoid_returning_this
# Prevents logical inconsistencies. It's good practice to define getters for all existing setters.
# https://dart-lang.github.io/linter/lints/avoid_setters_without_getters.html
#- avoid_setters_without_getters
# Don't reuse a type parameter when on with the same name already exists in the same scope
#
# https://dart-lang.github.io/linter/lints/avoid_shadowing_type_parameters.html
#- avoid_shadowing_type_parameters
# A single cascade operator can be replaced with a normal method call
#
# https://dart-lang.github.io/linter/lints/avoid_single_cascade_in_expression_statements.html
#- avoid_single_cascade_in_expression_statements
# Might cause frame drops because of synchronous file access on mobile, especially on older phones with slow storage.
# There are no known measurements sync access does *not* drop frames.
#
# https://dart-lang.github.io/linter/lints/avoid_slow_async_io.html
# - avoid_slow_async_io
# Don't use .toString() in production code which might be minified
# Dart SDK: >= 2.10.0-144.0.dev • (Linter v0.1.119)
# https://dart-lang.github.io/linter/lints/avoid_type_to_string.html
#- avoid_type_to_string
# Don't use a parameter names which can be confused with a types (i.e. int, bool, num, ...)
#
# https://dart-lang.github.io/linter/lints/avoid_types_as_parameter_names.html
#- avoid_types_as_parameter_names
# Adding the type is not required, but sometimes improves readability. Therefore removing it doesn't always help
# https://dart-lang.github.io/linter/lints/avoid_types_on_closure_parameters.html
# - avoid_types_on_closure_parameters
# Containers without parameters have no effect and can be removed
# https://dart-lang.github.io/linter/lints/avoid_unnecessary_containers.html
#- avoid_unnecessary_containers
# Unused parameters should be removed
# https://dart-lang.github.io/linter/lints/avoid_unused_constructor_parameters.html
#- avoid_unused_constructor_parameters
# For async functions use `Future<void>` as return value, not `void`
# This allows usage of the await keyword and prevents operations from running in parallel.
#
# https://dart-lang.github.io/linter/lints/avoid_void_async.html
#- avoid_void_async
# Flutter mobile only: Web packages aren't available in mobile flutter apps
# https://dart-lang.github.io/linter/lints/avoid_web_libraries_in_flutter.html
#- avoid_web_libraries_in_flutter
# Use the await keyword only for futures. There is nothing to await in synchronous code
#
# https://dart-lang.github.io/linter/lints/await_only_futures.html
#- await_only_futures
# Follow the style guide and use UpperCamelCase for extensions
#
# https://dart-lang.github.io/linter/lints/camel_case_extensions.html
#- camel_case_extensions
# Follow the style guide and use UpperCamelCase for class names and typedefs
#
# https://dart-lang.github.io/linter/lints/camel_case_types.html
#- camel_case_types
# Prevents leaks and code executing after their lifecycle.
# Discussion https://github.com/passsy/dart-lint/issues/4
#
#
# https://dart-lang.github.io/linter/lints/cancel_subscriptions.html
#- cancel_subscriptions
# The cascade syntax is weird and you shouldn't be forced to use it.
# False positives:
# https://github.com/dart-lang/linter/issues/1589
#
# https://dart-lang.github.io/linter/lints/cascade_invocations.html
# - cascade_invocations
# Don't cast T? to T. Use ! instead
# Dart SDK: >= 2.11.0-182.0.dev • (Linter v0.1.120)
# https://dart-lang.github.io/linter/lints/cast_nullable_to_non_nullable.html
#- cast_nullable_to_non_nullable
# False positives, not reliable enough
# - https://github.com/dart-lang/linter/issues/1381
#
#
# https://dart-lang.github.io/linter/lints/close_sinks.html
# - close_sinks
# False positives:
# - https://github.com/dart-lang/linter/issues/1142
#
# https://dart-lang.github.io/linter/lints/comment_references.html
# - comment_references
# Checks that files in conditional imports exist
#
# Linter v1.16.0
# https://dart-lang.github.io/linter/lints/conditional_uri_does_not_exist.html
#- conditional_uri_does_not_exist
# Follow standard dart naming style.
#
# https://dart-lang.github.io/linter/lints/constant_identifier_names.html
#- constant_identifier_names
# Prevents hard to debug code
#
# https://dart-lang.github.io/linter/lints/control_flow_in_finally.html
#- control_flow_in_finally
# Single line `if`s are fine, but when a new line splits the bool expression and body curly braces
# are recommended. It prevents the danging else problem and easily allows the addition of more lines inside
# the if body
#
# Dart SDK: >= 2.0.0 • (Linter v0.1.57)
#
# https://dart-lang.github.io/linter/lints/curly_braces_in_flow_control_structures.html
#- curly_braces_in_flow_control_structures
# Requires all referenced dependencies to be declared as direct dependencies in pubspec.yaml. Transitive
# dependencies might be removed by a dependency, breaking your code.
#
# Dart SDK: 2.14.0-172.0.dev • (Linter v1.5.0)
#
# https://dart-lang.github.io/linter/lints/depend_on_referenced_packages.html
#- depend_on_referenced_packages
# When deprecating classes, also deprecate the constructor. When deprecating fields, also deprecate the constructor
# parameter. That rule is useful for apps and especially for packages
#
# Dart SDK: 2.13.0 • (Linter v1.0.0)
#
# https://dart-lang.github.io/linter/lints/deprecated_consistency.html
#- deprecated_consistency
# Still experimental and pretty much work when enforced
# https://dart-lang.github.io/linter/lints/diagnostic_describe_all_properties.html
# - diagnostic_describe_all_properties
# Follows dart style. Fully supported by IDEs and no manual effort for a consistent style
#
# https://dart-lang.github.io/linter/lints/directives_ordering.html
#- directives_ordering
# String.fromEnvironment looks up env variables at compile time. The variable is baked in by the compiler
# and can't be changed by environment variables.
#
# For dart apps:
# Better look up an environment variable at runtime with Platform.environment
# or use code generation to define variables at compile time.
#
# For Flutter apps:
# String.fromEnvironment is the recommended way to include variables defined with `flutter build --dart-define`
#
#
# Dart SDK: >= 2.10.0-0.0.dev • (Linter v0.1.117)
# https://dart-lang.github.io/linter/lints/do_not_use_environment.html
# - do_not_use_environment
# Add a comment why no further error handling is required
#
# https://dart-lang.github.io/linter/lints/empty_catches.html
#- empty_catches
# Removed empty constructor bodies
#
# https://dart-lang.github.io/linter/lints/empty_constructor_bodies.html
#- empty_constructor_bodies
# Don't allow empty if bodies. Works together with curly_braces_in_flow_control_structures
#
# https://dart-lang.github.io/linter/lints/empty_statements.html
#- empty_statements
# That's good habit, but not necessary. It might be useful for some parsers that split lines based on the
# new line character. Common in simple bash scripts.
#
# Most IDEs do this automatically, therefore zero effort for devs
#
# Dart SDK: >=2.14.0-360.0.dev • (Linter v1.8.0)
#
# https://dart-lang.github.io/linter/lints/eol_at_end_of_file.html
#- eol_at_end_of_file
# Enums aren't powerful enough, now enum like classes get the same linting support
#
# Dart SDK: >= 2.9.0-12.0.dev • (Linter v0.1.116)
#
# https://dart-lang.github.io/linter/lints/exhaustive_cases.html
#- exhaustive_cases
# Follow dart file naming schema
# https://dart-lang.github.io/linter/lints/file_names.html
#- file_names
# Very flutter specific, not applicable for all projects
#
# https://dart-lang.github.io/linter/lints/flutter_style_todos.html
# - flutter_style_todos # not all todos require a ticket
# hashCode and equals need to be consistent. One can't live without another.
# https://dart-lang.github.io/linter/lints/hash_and_equals.html
#- hash_and_equals
# DON'T import implementation files from another package.
# If you need access to some internal code, create an issue
# https://dart-lang.github.io/linter/lints/implementation_imports.html
#- implementation_imports
# Although there are some false positives, this lint generally catches unnecessary checks
# - https://github.com/dart-lang/linter/issues/811
#
#
# https://dart-lang.github.io/linter/lints/invariant_booleans.html
#- invariant_booleans
# Type check for `Iterable<T>.contains(other)` where `other is! T`
# Without this, `contains` will always report false. Those errors are usually very hard to catch.
#
# https://dart-lang.github.io/linter/lints/iterable_contains_unrelated_type.html
#- iterable_contains_unrelated_type
# Hint to join return and assignment.
#
# https://dart-lang.github.io/linter/lints/join_return_with_assignment.html
#- join_return_with_assignment
# Add leading \n which which makes multiline strings easier to read
# Dart SDK: >= 2.8.0-dev.16.0 • (Linter v0.1.113)
# https://dart-lang.github.io/linter/lints/leading_newlines_in_multiline_strings.html
#- leading_newlines_in_multiline_strings
# Makes sure a library name is a valid dart identifier.
# This comes in handy for test files combining multiple tests where the file name can be used as identifier
#
# ```
# import src/some_test.dart as some_test;
#
# main() {
# some_test.main();
# }
# ```
#
# https://dart-lang.github.io/linter/lints/library_names.html
#- library_names
# Follow dart style
#
# https://dart-lang.github.io/linter/lints/library_prefixes.html
#- library_prefixes
# Nobody wants to manually wrap lines when changing a few words. This rule is too hard to be a "general" rule
#
# https://dart-lang.github.io/linter/lints/lines_longer_than_80_chars.html
# - lines_longer_than_80_chars
# Type check for List<T>.remove(item) where item is! T
# The list can't contain item. Those errors are not directly obvious especially when refactoring.
# https://dart-lang.github.io/linter/lints/list_remove_unrelated_type.html
#- list_remove_unrelated_type
# Good for libraries to prevent unnecessary code paths.
# False positives may occur for applications when boolean properties are generated by external programs
# producing auto-generated source code
#
# Known issue: while(true) loops https://github.com/dart-lang/linter/issues/453
#
#
# https://dart-lang.github.io/linter/lints/literal_only_boolean_expressions.html
# - literal_only_boolean_expressions
# Don't forget the whitespaces at the end
#
# Dart SDK: >= 2.8.0-dev.10.0 • (Linter v0.1.110)
#
# https://dart-lang.github.io/linter/lints/missing_whitespace_between_adjacent_strings.html
#- missing_whitespace_between_adjacent_strings
# Concat Strings obviously with `+` inside a list.
#
# https://dart-lang.github.io/linter/lints/no_adjacent_strings_in_list.html
#- no_adjacent_strings_in_list
# Second case is basically dead code which will never be reached.
#
# https://dart-lang.github.io/linter/lints/no_duplicate_case_values.html
#- no_duplicate_case_values
# private library prefixes don't exist, don't try to introduce concepts that have no effect
#
# Linter v1.15
# https://dart-lang.github.io/linter/lints/no_leading_underscores_for_library_prefixes.html
#- no_leading_underscores_for_library_prefixes
# private identifier prefixes don't exist, don't try to introduce concepts that have no effect
#
# Linter v1.15
# https://dart-lang.github.io/linter/lints/no_leading_underscores_for_local_identifiers.html
#- no_leading_underscores_for_local_identifiers
# Flutter only: `createState` shouldn't pass information into the state
#
# https://dart-lang.github.io/linter/lints/no_logic_in_create_state.html
#- no_logic_in_create_state
# calling `runtimeType` may be a performance problem
# Dart SDK: >= 2.8.0-dev.10.0 • (Linter v0.1.110)
# https://dart-lang.github.io/linter/lints/no_runtimeType_toString.html
#- no_runtimeType_toString
# Follow dart style naming conventions
#
# https://dart-lang.github.io/linter/lints/non_constant_identifier_names.html
#- non_constant_identifier_names
# Don't call unnecessary conversion methods on primitives
#
# Dart SDK: 2.14.0-172.0.dev • (Linter v1.5.0)
#
# https://dart-lang.github.io/linter/lints/noop_primitive_operations.html
#- noop_primitive_operations
# Generic T might have a value of String or String?. Both are valid.
# This lint triggers when ! is used on T? casting (String?)? to String and not (String?)? to String?
# Dart SDK: >= 2.11.0-182.0.dev • (Linter v0.1.120)
# https://dart-lang.github.io/linter/lints/null_check_on_nullable_type_parameter.html
#- null_check_on_nullable_type_parameter
# Might become irrelevant when non-nullable types land in dart. Until then use this lint check which checks for
# non null arguments for specific dart sdk methods.
#
# https://dart-lang.github.io/linter/lints/null_closures.html
#- null_closures
# Types for local variables can improve readability and shouldn't be forced to be removed.
#
# Dart SDK: >= 2.0.0 • (Linter v0.1.30)
#
# https://dart-lang.github.io/linter/lints/omit_local_variable_types.html
# - omit_local_variable_types
# Defining interfaces (abstract classes), with only one method, makes sense architecture wise
# Discussion: https://github.com/passsy/dart-lint/issues/2
#
#
# https://dart-lang.github.io/linter/lints/one_member_abstracts.html
# - one_member_abstracts
# Since Errors aren't intended to be caught (see avoid_catching_errors), throwing anything
# doesn't cause trouble.
# https://dart-lang.github.io/linter/lints/only_throw_errors.html
# - only_throw_errors
# Highlights unintentionally overridden fields.
# https://dart-lang.github.io/linter/lints/overridden_fields.html
#- overridden_fields
# Only relevant for packages, not applications or general dart code
# https://dart-lang.github.io/linter/lints/package_api_docs.html
# - package_api_docs
# Follow dart style package naming convention
#
# Dart SDK: >= 2.0.0 • (Linter v0.1.31)
#
# https://dart-lang.github.io/linter/lints/package_names.html
#- package_names
# Seems very rare, especially for applications.
# https://dart-lang.github.io/linter/lints/package_prefixed_library_names.html
#- package_prefixed_library_names
# Most likely a mistake, if not: bad practice
#
# https://dart-lang.github.io/linter/lints/parameter_assignments.html
#- parameter_assignments
# Is contradictory to `no_adjacent_strings_in_list`
#
# https://dart-lang.github.io/linter/lints/prefer_adjacent_string_concatenation.html
# - prefer_adjacent_string_concatenation
# Makes it easier to migrate to const constructors and to have final fields
#
# https://dart-lang.github.io/linter/lints/prefer_asserts_in_initializer_lists.html
#- prefer_asserts_in_initializer_lists
# Assertions blocks don't require a message because they throw simple to understand errors
#
# https://dart-lang.github.io/linter/lints/prefer_asserts_with_message.html
# - prefer_asserts_with_message
# Collection literals are shorter. They exists, use them.
#
# https://dart-lang.github.io/linter/lints/prefer_collection_literals.html
#- prefer_collection_literals
# Use the ??= operator when possible
#
# https://dart-lang.github.io/linter/lints/prefer_conditional_assignment.html
#- prefer_conditional_assignment
# Always use const when possible, make runtime faster
#
# https://dart-lang.github.io/linter/lints/prefer_const_constructors.html
#- prefer_const_constructors
# Add a const constructor when possible
#
# https://dart-lang.github.io/linter/lints/prefer_const_constructors_in_immutables.html
#- prefer_const_constructors_in_immutables
# final is good, const is better
# https://dart-lang.github.io/linter/lints/prefer_const_declarations.html
#- prefer_const_declarations
# Always use const when possible, make runtime faster
#
# https://dart-lang.github.io/linter/lints/prefer_const_literals_to_create_immutables.html
#- prefer_const_literals_to_create_immutables
# Dart has named constructors. Static methods in other languages (java) are a workaround which don't have
# named constructors.
#
# https://dart-lang.github.io/linter/lints/prefer_constructors_over_static_methods.html
#- prefer_constructors_over_static_methods
# Contains may be faster and is easier to read
#
# https://dart-lang.github.io/linter/lints/prefer_contains.html
#- prefer_contains
# Use whatever makes you happy. lint doesn't define a style
# Conflicts with prefer_single_quotes
#
# https://dart-lang.github.io/linter/lints/prefer_double_quotes.html
# - prefer_double_quotes
# Prevent confusion with call-side when using named parameters
#
# https://dart-lang.github.io/linter/lints/prefer_equal_for_default_values.html
#- prefer_equal_for_default_values
# Single line methods + implementation makes it hard to write comments for that line.
# Dense code isn't necessarily better code.
#
# https://dart-lang.github.io/linter/lints/prefer_expression_function_bodies.html
# - prefer_expression_function_bodies
# Avoid accidental reassignments and allows the compiler to do optimizations.
#
# https://dart-lang.github.io/linter/lints/prefer_final_fields.html
#- prefer_final_fields
# Helps avoid accidental reassignments and allows the compiler to do optimizations.
#
# https://dart-lang.github.io/linter/lints/prefer_final_in_for_each.html
#- prefer_final_in_for_each
# Helps avoid accidental reassignments and allows the compiler to do optimizations.
#
# https://dart-lang.github.io/linter/lints/prefer_final_locals.html
#- prefer_final_locals
# While prefer_final_fields and prefer_final_locals is enabled, this lint would add a lot of clutter to methods,
# especially lambdas.
# parameter_assignments is already enabled, catching this error
# Conflicts with avoid_final_parameters
#
# Dart SDK: 2.14.0-172.0.dev • (Linter v1.5.0)
#
# https://dart-lang.github.io/linter/lints/prefer_final_parameters.html
# - prefer_final_parameters
# Saves lot of code
#
# https://dart-lang.github.io/linter/lints/prefer_for_elements_to_map_fromIterable.html
#- prefer_for_elements_to_map_fromIterable
# Dense code isn't necessarily better code
#
# https://dart-lang.github.io/linter/lints/prefer_foreach.html
# - prefer_foreach
# As Dart allows local function declarations, it is a good practice to use them in the place of function literals.
# https://dart-lang.github.io/linter/lints/prefer_function_declarations_over_variables.html
#- prefer_function_declarations_over_variables
# For consistency
#
# https://dart-lang.github.io/linter/lints/prefer_generic_function_type_aliases.html
#- prefer_generic_function_type_aliases
# Allows potential usage of const
# https://dart-lang.github.io/linter/lints/prefer_if_elements_to_conditional_expressions.html
#- prefer_if_elements_to_conditional_expressions
# Dart has a special operator for this, use it
#
# https://dart-lang.github.io/linter/lints/prefer_if_null_operators.html
#- prefer_if_null_operators
# Terser code
# https://dart-lang.github.io/linter/lints/prefer_initializing_formals.html
#- prefer_initializing_formals
# Easier move towards const, and way easier to read
#
# https://dart-lang.github.io/linter/lints/prefer_inlined_adds.html
#- prefer_inlined_adds
# There is no argument which makes int literals better than double literals for doubles.
#
# https://dart-lang.github.io/linter/lints/prefer_int_literals.html
# - prefer_int_literals
# Interpolate, use less "", '' and +
# https://dart-lang.github.io/linter/lints/prefer_interpolation_to_compose_strings.html
#- prefer_interpolation_to_compose_strings
# Iterables do not necessary know their length
#
# https://dart-lang.github.io/linter/lints/prefer_is_empty.html
#- prefer_is_empty
# Easier to read
#
# Dart SDK: >= 2.0.0 • (Linter v0.1.5)
#
# https://dart-lang.github.io/linter/lints/prefer_is_not_empty.html
#- prefer_is_not_empty
# Use the `foo is! Foo` instead of `!(foo is Foo)`
# https://dart-lang.github.io/linter/lints/prefer_is_not_operator.html
#- prefer_is_not_operator
# Easier to read
#
# https://dart-lang.github.io/linter/lints/prefer_iterable_whereType.html
#- prefer_iterable_whereType
# Users of a 3rd party mixins can't change 3rd party code to use the mixin syntax.
# This makes the rule useless
# https://dart-lang.github.io/linter/lints/prefer_mixin.html
# - prefer_mixin
# It's shorter and should be preferred. Especially helpful for devs new to dart.
#
# Dart SDK: 2.14.0-2.0.dev • (Linter v1.3.0)
#
# https://dart-lang.github.io/linter/lints/prefer_null_aware_method_calls.html
#- prefer_null_aware_method_calls
# Makes expressions with null checks easier to read.
# https://github.com/flutter/flutter/pull/32711#issuecomment-492930932
#- prefer_null_aware_operators
# Conflicting with `avoid_relative_lib_imports` which is enforced
# https://dart-lang.github.io/linter/lints/prefer_relative_imports.html
# - prefer_relative_imports
# Use whatever makes you happy. lint doesn't define a style
# Conflicts with prefer_double_quotes
#
# https://dart-lang.github.io/linter/lints/prefer_single_quotes.html
# - prefer_single_quotes
# Allows potential usage of const
#
# https://dart-lang.github.io/linter/lints/prefer_spread_collections.html
#- prefer_spread_collections
# Define types
#
# https://dart-lang.github.io/linter/lints/prefer_typing_uninitialized_variables.html
#- prefer_typing_uninitialized_variables
# Null is not a type, use void
# https://dart-lang.github.io/linter/lints/prefer_void_to_null.html
#- prefer_void_to_null
# Document the replacement API
# https://dart-lang.github.io/linter/lints/provide_deprecation_message.html
#- provide_deprecation_message
# Definitely not a rule for standard dart code. Maybe relevant for packages
# https://dart-lang.github.io/linter/lints/public_member_api_docs.html
# - public_member_api_docs
# Hints accidental recursions
#
# https://dart-lang.github.io/linter/lints/recursive_getters.html
#- recursive_getters
# Dartfmt formats differently when adding trailing commas. This lint makes sure there is zero doubt in how code
# should be formatted.
#
# This rule is debatable, though.
# A non-representative [vote](https://twitter.com/passsy/status/1427220769050972162) shows a strong tendency towards
# enabling this rule. Especially because the code example does only include the debatable formatting changes. There
# are more, especially in Flutter build methods which make the code clearly better.
#
# Dart SDK: 2.14.0-2.0.dev • (Linter v1.3.0)
#
# https://dart-lang.github.io/linter/lints/require_trailing_commas.html
#- require_trailing_commas
# Use https in pubspec.yaml
#
# Linter v1.15
# https://dart-lang.github.io/linter/lints/secure_pubspec_urls.html
#- secure_pubspec_urls
# Flutter only, prefer SizedBox over Container which offers a const constructors
# Dart SDK: >= 2.9.0-4.0.dev • (Linter v0.1.115)
# https://dart-lang.github.io/linter/lints/sized_box_for_whitespace.html
#- sized_box_for_whitespace
# Use the SizeBox.expand or SizeBox.shrink constructor instead of setting both width and height
# to `0` or `double.infinity`
#
# Linter v1.15
# https://dart-lang.github.io/linter/lints/sized_box_shrink_expand.html
#- sized_box_shrink_expand
# Follow dart style use triple slashes
#
# https://dart-lang.github.io/linter/lints/slash_for_doc_comments.html
#- slash_for_doc_comments
# Flutter only, always put child last
#
# https://dart-lang.github.io/linter/lints/sort_child_properties_last.html
#- sort_child_properties_last
# Working, results in consistent code. But too opinionated
# Discussion: https://github.com/passsy/dart-lint/issues/1
#
#
# https://dart-lang.github.io/linter/lints/sort_constructors_first.html
# - sort_constructors_first
# Any sorting is better than no sorting
# https://dart-lang.github.io/linter/lints/sort_pub_dependencies.html
#- sort_pub_dependencies
# Default constructor comes first.
#
# https://dart-lang.github.io/linter/lints/sort_unnamed_constructors_first.html
#- sort_unnamed_constructors_first
# First test, then cast
#
# https://dart-lang.github.io/linter/lints/test_types_in_equals.html
#- test_types_in_equals
# Hard to debug and bad style
#
# https://dart-lang.github.io/linter/lints/throw_in_finally.html
#- throw_in_finally
# Help the compiler at compile time with non-null asserts rather than crashing at runtime
# Dart SDK: >= 2.11.0-182.0.dev • (Linter v0.1.120)
# https://dart-lang.github.io/linter/lints/tighten_type_of_initializing_formals.html
#- tighten_type_of_initializing_formals
# Type annotations make the compiler intelligent, use them
# https://dart-lang.github.io/linter/lints/type_annotate_public_apis.html
#- type_annotate_public_apis
# Don't add types for already typed constructor parameters.
#
# https://dart-lang.github.io/linter/lints/type_init_formals.html
#- type_init_formals
# Too many false positives.
# Using the pedantic package for the unawaited function doesn't make code better readable
#
#
# https://dart-lang.github.io/linter/lints/unawaited_futures.html
# - unawaited_futures
# Remove async/await clutter when not required
# https://dart-lang.github.io/linter/lints/unnecessary_await_in_return.html
#- unnecessary_await_in_return
# Remove unnecessary braces
#
# https://dart-lang.github.io/linter/lints/unnecessary_brace_in_string_interps.html
#- unnecessary_brace_in_string_interps
# Yes, const everywhere. But not in an already const scope
#
# https://dart-lang.github.io/linter/lints/unnecessary_const.html
#- unnecessary_const
# Disabled because `final` prevents accidental reassignment
# https://dart-lang.github.io/linter/lints/unnecessary_final.html
# - unnecessary_final
# Getter/setters can be added later on in a non API breaking manner
#
# https://dart-lang.github.io/linter/lints/unnecessary_getters_setters.html
#- unnecessary_getters_setters
# Flutter setState is a good example where a lambda should always be used.
# https://github.com/dart-lang/linter/issues/498
#
# Some generic code sometimes requires lambdas, otherwise the generic type isn't forwarded correctly.
#
# https://dart-lang.github.io/linter/lints/unnecessary_lambdas.html
# - unnecessary_lambdas
# Top-level and static variables with initializers are already evaluated lazily as if they are marked late
#
# Linter v1.17
# https://dart-lang.github.io/linter/lints/unnecessary_late.html
#- unnecessary_late
# Remove the optional `new` keyword
#
# https://dart-lang.github.io/linter/lints/unnecessary_new.html
#- unnecessary_new
# Don't assign `null` when value is already `null`.
#
# https://dart-lang.github.io/linter/lints/unnecessary_null_aware_assignments.html
#- unnecessary_null_aware_assignments
# Remove ! when already non-nullable
# Dart SDK: >= 2.10.0-144.0.dev • (Linter v0.1.119)
# https://dart-lang.github.io/linter/lints/unnecessary_null_checks.html
#- unnecessary_null_checks
# Don't assign `null` when value is already `null`.
#
# https://dart-lang.github.io/linter/lints/unnecessary_null_in_if_null_operators.html
#- unnecessary_null_in_if_null_operators
# If a variable doesn't change and is initialized, no need to define it as nullable (NNDB)
# Dart SDK: >= 2.10.0-10.0.dev • (Linter v0.1.118)
# https://dart-lang.github.io/linter/lints/unnecessary_nullable_for_final_variable_declarations.html
#- unnecessary_nullable_for_final_variable_declarations
# Remove overrides which simply call super
# https://dart-lang.github.io/linter/lints/unnecessary_overrides.html
#- unnecessary_overrides
# Remove clutter where possible
# https://dart-lang.github.io/linter/lints/unnecessary_parenthesis.html
#- unnecessary_parenthesis
# Use raw string only when needed
# Dart SDK: >= 2.8.0-dev.11.0 • (Linter v0.1.111)
# https://dart-lang.github.io/linter/lints/unnecessary_raw_strings.html
#- unnecessary_raw_strings
# Avoid magic overloads of + operators
# https://dart-lang.github.io/linter/lints/unnecessary_statements.html
#- unnecessary_statements
# Remove unnecessary escape characters
# Dart SDK: >= 2.8.0-dev.11.0 • (Linter v0.1.111)
# https://dart-lang.github.io/linter/lints/unnecessary_string_escapes.html
#- unnecessary_string_escapes
# Completely unnecessary code, simplify to save a few CPU cycles
#
# Dart SDK: >= 2.8.0-dev.10.0 • (Linter v0.1.110)
#
# https://dart-lang.github.io/linter/lints/unnecessary_string_interpolations.html
#- unnecessary_string_interpolations
# The variable is clear, remove clutter
#
# https://dart-lang.github.io/linter/lints/unnecessary_this.html
#- unnecessary_this
# Highlights potential bugs where unrelated types are compared with another. (always *not* equal).
#
# https://dart-lang.github.io/linter/lints/unrelated_type_equality_checks.html
#- unrelated_type_equality_checks
# Web only
#
# https://dart-lang.github.io/linter/lints/unsafe_html.html
#- unsafe_html
# Very useful in preventing Flutter BuildContext bugs in async callbacks
#
# Dart SDK: 2.13.0 • (Linter v1.1.0)
#
# https://dart-lang.github.io/linter/lints/use_build_context_synchronously.html
#- use_build_context_synchronously
# Yet another "Container might be overkill" lint
#
# Linter v1.15
# https://dart-lang.github.io/linter/lints/use_decorated_box.html
#- use_decorated_box
# Always use hex syntax Color(0x00000001), never Color(1)
#
# https://dart-lang.github.io/linter/lints/use_full_hex_values_for_flutter_colors.html
#- use_full_hex_values_for_flutter_colors
# Always use generic function type syntax, don't mix styles
#
# https://dart-lang.github.io/linter/lints/use_function_type_syntax_for_parameters.html
#- use_function_type_syntax_for_parameters
# Don't use the modulo operator for isEven/isOdd checks
#
# Linter v0.1.116
# https://dart-lang.github.io/linter/lints/use_is_even_rather_than_modulo.html
#- use_is_even_rather_than_modulo
# Write `if (nullableBool ?? false)` instead of `if (nullableBool == true)`
# Not enabled, because `nullableBool == true` is very explicit, whereas `nullableBool ?? false` requires
# cognitive effort to process
#
# Dart SDK: 2.13.0 • (Linter v1.0.0)
#
# https://dart-lang.github.io/linter/lints/use_if_null_to_convert_nulls_to_bools.html
# - use_if_null_to_convert_nulls_to_bools
# Replace const values with predefined constants
# `const Duration(seconds: 0)` -> `Duration.zero`
#
# Dart SDK: 2.13.0 • (Linter v1.0.0)
#
# https://dart-lang.github.io/linter/lints/use_named_constants.html
#- use_named_constants
# Adding a key without using it isn't helpful in applications, only for the Flutter SDK
# Dart SDK: >= 2.8.0-dev.1.0 • (Linter v0.1.108)
# https://dart-lang.github.io/linter/lints/use_key_in_widget_constructors.html
# - use_key_in_widget_constructors
# Some might argue `late` is a code smell, this lint is very opinionated. It triggers only for private fields and
# therefore might actually cleanup some code.
# There is no performance impact either way https://github.com/dart-lang/linter/pull/2189#discussion_r457945301
#
# Dart SDK: >= 2.10.0-10.0.dev • (Linter v0.1.118)
#
# https://dart-lang.github.io/linter/lints/use_late_for_private_fields_and_variables.html
#- use_late_for_private_fields_and_variables
# Use rethrow to preserve the original stacktrace.
# https://dart.dev/guides/language/effective-dart/usage#do-use-rethrow-to-rethrow-a-caught-exception
#
# Dart SDK: >= 2.0.0 • (Linter v0.1.31)
#
# https://dart-lang.github.io/linter/lints/use_rethrow_when_possible.html
#- use_rethrow_when_possible
# Use the setter syntax
#
# https://dart-lang.github.io/linter/lints/use_setters_to_change_properties.html
#- use_setters_to_change_properties
# In most cases, using a string buffer is preferred for composing strings due to its improved performance.
# https://dart-lang.github.io/linter/lints/use_string_buffers.html
#- use_string_buffers
# Don't use try-catch with fail(), instead catch the error with the `throwsA` matcher. The big advantage:
# When another error is thrown, the assertion fails whereas catching a specific error would miss the catch block
#
# Dart SDK: 2.14.0-172.0.dev • (Linter v1.5.0)
#
# https://dart-lang.github.io/linter/lints/use_test_throws_matchers.html
#- use_test_throws_matchers
# Naming is hard, strict rules don't help
#
# https://dart-lang.github.io/linter/lints/use_to_and_as_if_applicable.html
# - use_to_and_as_if_applicable
# Catches invalid regular expressions.
#
# https://dart-lang.github.io/linter/lints/valid_regexps.html
#- valid_regexps
# Don't assign anything to void
# https://dart-lang.github.io/linter/lints/void_checks.html
#- void_checksEnjoyed the article? Feel free to show your appreciation with a round of applause! 👏👏👏
