Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
RydMike lints v1.2.9 - Personal preferences and my starting point for my Dart & Flutter linter rules setup
# RydMike LINTER Preferences v2.0.0
#
# Get this file here: https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#
# We include and activate all lint rules, later below we disable the not used or desired ones.
# You can find a list of all lint rules to put in your all_lint_rules.yaml file here:
# https://dart-lang.github.io/linter/lints/options/options.html
#
# For a full comparison of all lint rules settings in rule styles listed below, please see this
# sheet: https://docs.google.com/spreadsheets/d/1Nc1gFjmCOMubWZD7f2E4fLhWN7LYaOE__tsA7bf2NjA
#
# The version used for comparing setting with other linters for the settings
# that are turned OFF here, or have a quick placeholder for turning it OFF, are
# as follows:
#
# Core v2.0.0 : https://pub.dev/packages/lints
# Recommended v2.0.0 : https://pub.dev/packages/lints
# Flutter Lints v2.0.1 : https://pub.dev/packages/flutter_lints
# Pedantic v1.11.1 : https://pub.dev/packages/pedantic
# Effective Dart v1.3.2 : https://pub.dev/packages/effective_dart
# Flutter repo master : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint v1.8.2 : https://pub.dev/packages/lint
# VG Analysis v3.0.0 : https://pub.dev/packages/very_good_analysis
# RydMike v2.0.0 : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#
include: all_lint_rules.yaml
analyzer:
exclude:
- "**/*.g.dart"
- "**/*.freezed.dart"
- "test/.test_coverage.dart"
- "bin/cache/**"
- "lib/generated_plugin_registrant.dart"
# For more information see:
# https://dart.dev/guides/language/analysis-options#enabling-additional-type-checks
language:
strict-casts: true
strict-inference: true
strict-raw-types: true
errors:
# Without ignore here, we cause import of all_lint_rules to warn, because some rules conflict.
# We explicitly enabled even conflicting rules and are fixing the conflicts in this file.
# Put it to warning temporarily, if you need troubleshoot lint rule settings.
included_file_warning: ignore
# Treat missing required parameters as an error, not as a hint or a warning.
missing_required_param: error
# Treat missing returns as an error, not as a hint or a warning.
missing_return: error
# Allow self-reference to deprecated members. This is done because otherwise we have
# to annotate every member in every test, assert, etc., when we deprecate something.
deprecated_member_use_from_same_package: ignore
# DON'T assign new values to parameters of methods or functions.
#
# https://dart-lang.github.io/linter/lints/parameter_assignments.html
#
# Treat assigning new values to a parameter as a warning. We would almost like to set this
# to an error. However, this warning rule or even more so if set to an error, can sometimes
# be a bit problematic you include other code directly that does it a lot.
# It does however, make code safer when this cannot be done without involving
# an extra local variable for clarity and safety. Enabling this error, even as just a warning,
# does get in the way a bit if all you want to do is a null to default value release runtime
# safety/fallback assignment. For that use case you have to add a local rule override. With
# null-safety, the need for this kind of null check and re-assignment to default if null,
# is rarely needed. Considering the comment in:
# https://dart-lang.github.io/linter/lints/parameter_assignments.html:
# "Assigning new values to parameters is generally a bad practice unless an operator
# such as ??= is used. Otherwise, arbitrarily reassigning parameters is usually a mistake."
# One might even think the rule would allow using the ??= operator, but it does not. For now,
# we keep this lint as warning and overriding locally with:
#
# When we need it for the ??= operator, or some copy/paste in of some code that does things
# that needs it too, and that we don't want to deal with fixing at the moment.
parameter_assignments: warning
# Allow having TODOs in the code.
todo: ignore
# LINTER Preferences
#
# Explicitly disable only the rules we do not want.
linter:
rules:
# ALWAYS separate the control structure expression from its statement.
#
# https://dart-lang.github.io/linter/lints/always_put_control_body_on_new_line.html
#
# This sometimes makes things more unclear when one line is enough.
# Also single line `if`s are fine as recommended in Effective Dart "DO format your code using dartfmt".
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
always_put_control_body_on_new_line: false
# ALWAYS specify @required on named parameter before other named parameters.
#
# https://dart-lang.github.io/linter/lints/always_put_required_named_parameters_first.html
#
# Conflicts with the convention used by Flutter, which puts `Key key` first
# and `@required Widget child` last.
#
# Other known linters use:
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
always_put_required_named_parameters_first: false
# ALWAYS specify type annotations.
#
# https://dart-lang.github.io/linter/lints/always_specify_types.html
#
# Avoid var when specifying that a type is unknown and short-hands that elude type annotations. Use
# dynamic if you are being explicit that the type is unknown. Use Object if you are being explicit
# that you want an object that implements == and hashCode.
# The linter rule link above states this rule is from the Flutter style guide.
#
# This makes most code intent very explicit, sometimes this may help you
# reason about unfamiliar libs, but it might get tedious when dealing with very familiar ones.
# For people used to more relaxed or no type declaration, it is probably the other way around.
# This rule is of course also in conflict with some other lint rules, most notably it
# violates Effective Dart "AVOID type annotating initialized local variables".
# https://dart-lang.github.io/linter/lints/omit_local_variable_types.html
# Which we find to be a strange rule, the package lint agrees, with the statement that
# "Types for local variables may improve readability" and keeps that avoid rule disabled.
#
# Turning always_specify_types lint rule on in a project at later stage is very tedious, fixing
# all the analyzer warnings will take quite some time. Having it on as you write new code
# is not so bad though, the IDE will handle it most of the time.
# Most people probably want this lint rule OFF, but for now we try to keep it on
# in our projects. We might reconsider this choice later, for example this issue has requested
# a new softer related lint rule that could be used only for declarations:
# https://github.com/dart-lang/linter/issues/1620
# If such a lint rule materializes, we might switch to using it instead and turning this one off.
#
# We felt the above long explanation was warranted as a reminder. Keeping the rule listed here
# and the setting below, in order to easily turn it OFF permanently some day, or in some
# projects.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike enabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# always_specify_types: false
# ALWAYS use package imports for files in lib/.
#
# https://dart-lang.github.io/linter/lints/always_use_package_imports.html
#
# This rule conflicts with `prefer_relative_imports` so we turn it OFF.
# We are still conflicted about which version to use, keeping it this way for now, as support
# for relative imports have improved in both IDE's, but adding imports still often get imported as
# package imports, and then you have to edit them manually. The IDEs can help with fixing them.
# The relative paths can be a bit messy to keep track off, package imports are actually
# a bit easier from that point of view.
# Flutter repo now also prefers relative imports over packages imports, so that is
# another reason to use that.
#
# Use what you prefer, but you have to be consistent though, since mixing and matching can
# cause issues as the same file imported with the different options are considered to be
# different libs and code, even if it is the same file. This may impact functionality
# of e.g. singletons, service locators and increase code size.
#
# When you refactor and move folders with a lot of code in them, that other code depends
# on for imports via relative imports, then they get messed up by Flutter IDEs
# VS-Code and AS/IntelliJ. Both main Flutter IDEs may fail to correctly refactor moved folders
# and imports that depend on files in the moved folders.
#
# Other known linters use:
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
always_use_package_imports: false
# AVOID annotating with dynamic when not required.
#
# https://dart-lang.github.io/linter/lints/avoid_annotating_with_dynamic.html
#
# Violates Effective Dart "PREFER annotating with dynamic instead of letting inference fail", it
# also conflicts with strong mode disabling `implicit-dynamic`. Turning it OFF.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_annotating_with_dynamic: false
# AVOID catches without on clauses.
#
# https://dart-lang.github.io/linter/lints/avoid_catches_without_on_clauses.html
#
# Using catch clauses without on clauses make your code prone to encountering unexpected errors that
# won't be thrown (and thus will go unnoticed). BUT, there are situations where we voluntarily want to
# catch everything, especially as a library. https://github.com/dart-lang/linter/issues/3023
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_catches_without_on_clauses: false
# AVOID defining a class that contains only static members.
#
# https://dart-lang.github.io/linter/lints/avoid_classes_with_only_static_members.html
#
# Creating classes with the sole purpose of providing utility or otherwise static methods is discouraged
# in effective Dart. Dart allows functions to exist outside of classes for this very reason.
# Effective Dart says avoid classes with only static members:
# https://dart.dev/guides/language/effective-dart/design#avoid-defining-a-class-that-contains-only-static-members
# However, the Flutter style guide says use them when it makes sense:
# https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#begin-global-constant-names-with-prefix-k
# Colors is an example of such a class, but they still enable this rule in the repo though, go figure.
#
# Like Pedantic, we like util and static classes too, so we use them.
# We tried the Effective Dart style and used a of kConstants in different const files. This
# is more cumbersome to use than static classes. The import is simpler with static classes and
# the code looks cleaner. If you use a lot of constant files, importing them is more tedious,
# and you cannot enforce a given 'as' name to have a consistent name space prefix. A static
# class gives you that automatically, thus providing context for the constants and static functions.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_classes_with_only_static_members: false
# AVOID declaring parameters as final.
#
# https://dart-lang.github.io/linter/lints/avoid_final_parameters.html
#
# Declaring parameters as final can lead to unnecessarily verbose code,
# especially when using the "parameter_assignments" rule.
#
# This rule is turned off, so we can define final parameters when it makes
# sense to do so without triggering a lint rule.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_final_parameters: false
# AVOID positional boolean parameters.
#
# https://dart-lang.github.io/linter/lints/avoid_positional_boolean_parameters.html
#
# Positional boolean parameters are considered a bad practice because they are very ambiguous.
# Using named boolean parameters is much more readable because it inherently describes
# what the boolean value represents.
# In principle, we agree with the argument against positional booleans. However, positional booleans
# are OK when they are the ONLY boolean parameter in a callback, and also very handy when used in a
# model setter from the callback directly.
#
# Flutter API contains many callbacks with the signature: {void Function(bool) onChanged} often
# for UI toggle switches. To keep things tidy and clean with a model setter for such a callback,
# a setter method with a positional boolean is needed, a typical pattern is:
# Switch.adaptive(
# value: model.hideTooltips,
# onChanged: model.setHideTooltips,
# ),
#
# We are turning OFF this AVOID rule. Willing to reconsider if I get convinced there are better ways,
# and it does not get in the way of single none named bool callbacks.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_positional_boolean_parameters: false
# AVOID print calls in production code.
#
# https://dart-lang.github.io/linter/lints/avoid_print.html
#
# Our default is to have this rule enabled.
#
# Examples may want to print to the console, you might want to do so during development too. We keep the rule here
# to handily disable/enable as and when needed. This lint rule is a good way to find print statements that you
# may have used during development in code that should not have them in production, so at least before
# committing the code in such projects, make sure to keep this rule enabled by commenting it out here.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints enabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# RELEASE: enabled : By commenting it out. (default)
# DEVELOPMENT: disabled : Uncomment below if the warnings bother you during dev or making a console app.
# avoid_print: false
# AVOID redundant argument values.
#
# https://dart-lang.github.io/linter/lints/avoid_redundant_argument_values.html
#
# Using redundant (default) argument values can be useful for in-code documentation
# purposes and also handy as a template when trying different settings in Flutter. It is often
# quicker when dealing with not well known APIs to see parameter values in the call/constructor,
# instead of using the IDE to peek into its default to figure out what the defaults are.
# Occasionally leaving a few redundant default valued parameters in the code is not that bad
# when you are developing something new. For public packages you probably want to keep this
# rule enabled. I like to sometimes be explicit and specify values that are same as default one.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# PACKAGE: enabled : By commenting it out below, often a good idea in packages.
# APPLICATION: disabled : With false value.
avoid_redundant_argument_values: false
# AVOID annotating types for function expression parameters.
#
# https://dart-lang.github.io/linter/lints/avoid_catches_without_on_clauses.html
#
# Annotating types for function expression parameters is usually unnecessary because the
# parameter types can almost always be inferred from the context, thus making the practice redundant.
# However, since we are using `always_specify_types` we should not have this one ON either
# as it conflicts with it. Even if you do not do that, we still recommend keeping this rule OFF.
# While always specifying type on callbacks is certainly a bit tedious and not necessary,
# it can sometimes improve readability, so let's not force them to not be allowed.
# Then even if you don't use `always_specify_types`, it is possible to sometimes possible to
# specify them on closures when it improves readability of unfamiliar closures.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_types_on_closure_parameters: false
# DO Use the cascading style when successively invoking methods on the same reference.
#
# https://dart-lang.github.io/linter/lints/cascade_invocations.html
#
# We disable this rule, just a personal preference, using them is fine though,
# but let's not enforce it.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
cascade_invocations: false
# DO invoke close on instances of dart.core.Sink.
#
# https://dart-lang.github.io/linter/lints/close_sinks.html
#
# Disabling it, may generate false positives. https://github.com/dart-lang/linter/issues/1381.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#close_sinks: false
# DO reference all public properties in debug method implementations.
#
# https://dart-lang.github.io/linter/lints/diagnostic_describe_all_properties.html
#
# Consider using this lint rule if you are making a public Flutter package, for private ones and private apps
# we recommend keeping it off as you probably won't be making diagnostic properties for all your
# classes, unless you are using a data class lib that does it for you via code generation.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# PACKAGE: enabled : By commenting it out.
# APPLICATION: disabled : With false value. (Default, assume we are making an app most of the time.)
diagnostic_describe_all_properties: false
# DO Use Flutter TO-DO format.
#
# https://dart-lang.github.io/linter/lints/flutter_style_todos.html
#
# Use Flutter-style todos with GitHub username. Useful if you are coding in a
# larger team, if not you may also consider turning off the rule by removing
# its comment below.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike enabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#flutter_style_todos: false
# AVOID lines longer than 80 characters
#
# https://dart-lang.github.io/linter/lints/lines_longer_than_80_chars.html
#
# Using this rule will sometimes force a line of 81 characters to be split in two.
# As long as we try to respect that 80 characters limit, going slightly above is fine.
#
# For packages keep this rule enabled though, because the pub.dev dart format check will
# penalize package points if it does not adhere to strict Dart format rules, which
# requires max 80 char lines. This rule will then help you find cases where you go over
# and fix them manually when possible. Funny thing is that Flutter repo violates this rule, but
# if you do it in packages for pub.dev you get score deductions. We often disable this rule
# if this is not a package, so we keep it listed here as as a handy toggle.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# PACKAGE: enabled : By commenting it out. (Default, even if is not a package, we start with this.)
# APPLICATION: disabled : With false value. (When/if short lines become problematic. We sometimes like 100 chars.)
# lines_longer_than_80_chars: false
# DO define default behavior outside switch statements.
#
# https://dart-lang.github.io/linter/lints/no_default_cases.html
#
# An experimental lint rule maturity wise. I enabled it, it seems to work well.
# Remove the comment below if it is causing issues.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike enabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#no_default_cases: false
# CONSIDER omitting type annotations for local variables.
#
# https://dart-lang.github.io/linter/lints/omit_local_variable_types.html
#
# Conflicts with 'always_specify_types' that is used, so then we can't have this rule either,
# besides we like being verbose and specific. Why and when would omitting the type for local
# variables be a good thing anyway, be specific, is our take on this.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic enabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
omit_local_variable_types: false
# PREFER asserts with a message string.
#
# https://dart-lang.github.io/linter/lints/prefer_asserts_with_message.html
#
# When assertions fail it's not always simple to understand why. Adding a message to the
# assert function helps the developer to understand why the AssertionError occurs.
#
# While this is true, Dart does nowadays create very clear messages from assert terms by default.
# Flutter SDK does not use this rule or style. When you use code from it for customized
# widgets you will end up having to write your own messages for the code snippet.
#
# Rationale for not using this in Flutter SDK:
# "Assertions blocks don't require a message because they throw simple to understand errors"
#
# We agree, so we do not mind turning OFF this rule when it becomes tedious, but we start
# with it ON. With NNBD you also usually a lot less asserts than you did before in Dart code,
# since NNBD made almost all "not null" assertions unnecessary.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# PACKAGE: enabled : By commenting it out. (default)
# APPLICATION: disabled : With false value. (If it gets tedious in an app, we may turn it off)
# prefer_asserts_with_message: false
# PREFER to define constructors, instead of static methods to create instances.
#
# https://dart-lang.github.io/linter/lints/prefer_constructors_over_static_methods.html
#
# Dart has named constructors. Static methods in other languages (java) are a workaround which don't have
# named constructors. We don't mind this lint rule, it is OK, BUT we noticed that
# if you want/need to create instances of classes via static helpers in another class, that
# this lint rules complains about it. We are OK with preferring a named
# constructor over a static method to create an instance from within the same class.
# But this lint rule complained about the above usage too where we think it makes sense to use this.
# This rule currently complains about use cases that in some scenarios is impossible to comply with.
# Maybe this is another issue with this lint rule. We should investigate it further and report
# it, if it is. For now we disable this rule.
# A past now resolved issue with this lint rule was: https://github.com/dart-lang/linter/issues/2149
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
prefer_constructors_over_static_methods: false
# DO use double quotes where they wouldn't require additional escapes.
#
# https://dart-lang.github.io/linter/lints/prefer_double_quotes.html
#
# This rule is mostly about what style you want to use and enforce, if any.
# It of course conflicts with rule:
# `prefer_single_quotes` : "DO use single quotes where they wouldn't require additional escapes."
# https://dart-lang.github.io/linter/lints/prefer_single_quotes.html
#
# For us single quotes are easier to type. On our ISO keyboards it is next to Enter key, and
# we don't need the Shift plus the far to reach nr 2 key on R1 to type it. Also, we don't think
# they compromise on readability.
# Then again if you don't care and don't mind mixing and matching, then ALSO
# turning OFF `prefer_single_quotes` works fine too, and then you can use both options.
#
# We thought it was cleaner to stick to one style. Single quotes are easier to type for us,
# thus we turn OFF this `prefer_double_quotes` rule. There is another lint rules that recommends you
# to use double quotes when you otherwise would need to escape the single quote char, it works
# well when you use the prefer_single_quotes rule as well.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
prefer_double_quotes: false
# CONSIDER using => for short members whose body is a single return statement.
#
# https://dart-lang.github.io/linter/lints/prefer_expression_function_bodies.html
#
# Certainly good idea in many cases, but not always. For example not always suitable for Flutter, which may
# have a `build` method with a single return, but that return is still complex enough that a "body" is worth it,
# and it might not even fit on a single line.
# https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#consider-using--for-short-functions-and-methods
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
prefer_expression_function_bodies: false
# DO prefer declaring parameters as final if they are not reassigned in the function body.
#
# https://dart-lang.github.io/linter/lints/prefer_final_parameters.html
#
# Declaring parameters as final when possible is a good practice because it helps
# avoid accidental reassignments.
#
# Certainly good idea in many cases. There seems to be one "small" false positive issue with it.
# Lint is triggered by final constructor properties, eg a in
# `final int i;` the parameter `this.i` is not also final, which is not really needed
# since the property is final. However, this triggers the rule, unnecessarily in our opinion.
# We need to turn OFF this rule due to that.
#
# We turned OFF the rule. In a test project, after we cleaned up all that could be after Flutter 2.5 upgrade.
# There were still 150 positives from the rule, from above issue. So after having it on and doing cleanup
# where it could be used, we turned off the rule for now. Pity, it is a useful and nice rule otherwise.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
prefer_final_parameters: false
# DO use int literals rather than the corresponding double literal.
#
# https://dart-lang.github.io/linter/lints/prefer_int_literals.html
#
# This rule goes against the preferred style of being explicit with
# declarations and hides when a number is double, since we cannot declare it
# as 0.0 or 1.0 when it is double, it has to be 0 or 1, making it look
# like an integer, even if it is not. Sometimes doing that is OK, but let's
# not enforce it.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
prefer_int_literals: false
# DO document all public members.
#
# https://dart-lang.github.io/linter/lints/public_member_api_docs.html
#
# All non-overriding public members should be documented with /// doc-style comments.
# Not necessary for an app or the examples in a pub.dev package. I always enable this for
# public packages.
#
# NOTE: There is also the lint rule "package_api_docs", that is enabled as well via all being enabled.
# https://dart-lang.github.io/linter/lints/package_api_docs.html
# "DO provide doc comments for all public APIs.", is what it is supposed to do, but only for packages.
# However, if we turn OFF rule "public_member_api_docs", then the "package_api_docs" offers no warnings
# on missing API doc comments alone. So our conclusion for now is that this rule has to be used instead
# to ensure we find all APIs that should have documentation comments in a package as well.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# PACKAGE: enabled : By commenting it out. (My default, I start with this)
# APPLICATION: disabled : With false value. (But usually uncomment the false value if it is an app)
# public_member_api_docs: false
# DO use trailing commas for all function calls and declarations unless the function call or
# definition, from the start of the function name up to the closing parenthesis,
# fits in a single line.
#
# https://dart-lang.github.io/linter/lints/require_trailing_commas.html
#
# This rule forces commas even in places where it just adds extra lines that
# adds little value. There is also not a bulk dart fix for it:
# https://github.com/dart-lang/sdk/issues/47441
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
require_trailing_commas: false
# DO sort constructor declarations before other members.
#
# We do like this lint rule, but we want to have the default constructor first, followed
# by its properties, after this other named constructors and factories. This rule gets
# in the way of that and forces you to put (often final) constructor properties after all
# the named constructors and factories, making them tedious to find and disconnected from
# where we want to see, read and handily edit them. This is especially the case if there are
# many constructors and factories, and they have a lot of parameters. For now, we disable
# this rule and order things as described above, which apart from the default constructor
# properties coming right after the constructor, is the only part where we in practice
# deviate from this rule, so other yes, we do put constructors first as well anyway.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# Discussion https://github.com/passsy/dart-lint/issues/1
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
sort_constructors_first: false
# DON'T use final for local variables.
#
# https://dart-lang.github.io/linter/lints/unnecessary_final.html
#
# Incompatible with `prefer_final_locals` that we want because having immutable local variables when
# applicable makes larger functions more predictable and easier to reason about, so we
# use `prefer_final_locals` instead.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
unnecessary_final: false
@rydmike
Copy link
Author

rydmike commented Oct 14, 2020

My Dart & Flutter lint rules - A starting point

This is a starting point I often use for my Dart lint rules, with my personal rationale added as comments regarding why I went one way or another.

The starting point is a list of all lint rules that can be found here:
https://dart-lang.github.io/linter/lints/options/options.html

All lint rules are all first included and enabled and then the above setup just disables the conflicting ones or personally not desired ones. For public packages I keep a few more rules enabled as mentioned in the above comments.

I know the 'always_specify_types' rule is controversial and not really needed by Dart, but I like it for the reasons I mention in the comments. I might change my mind about it eventually, but keeping it for now in my own projects. The Flutter SDK uses it too by the way.

For more information please see my blog post on the topic: https://rydmike.com/blog_flutter_linting

Comparison of popular lint rules

For a table that compares all lint rules of many popular Dart and Flutter linting packages, please see this Google sheet:
https://docs.google.com/spreadsheets/d/1Nc1gFjmCOMubWZD7f2E4fLhWN7LYaOE__tsA7bf2NjA

Version history

  • Oct 15, 2020 - Version 1.0.0: First release
  • Jan 10, 2020 - Version 1.1.0: Added lint preference documentation and references to other style preferences.
  • Jul 28, 2021 - Version 1.2.0: First included version in Lint rule comparison sheet.
  • Jul 31, 2021 - Version 1.2.1: Spelling and language corrections
  • Aug 14, 2021 - Version 1.2.2: Added lib/generated_plugin_registrant.dart to excluded files.
  • Aug 25, 2021 - Version 1.2.3: Comment and documentation updates.
  • Sep 1, 2021 - Version 1.2.4: Fixes to the file, it was no longer triggering hints, unsure why, it now works again. No idea why I had to remove two lines that worked fine before. Investigating.
  • Sep 9, 2021 - Version 1.2.5: Flutter 2.5 upgrade. Disabled lints library_private_types_in_public_api and prefer_final_parameters. Linter also now works again with the two lines that were removed in 1.2.4 so they were added back as they should be there in the syntax. May have been an issue in Flutter 2.2.3 and having also lints enabled that were not yet in Dart SDK it used, in any case Flutter 2.5 fixed the issue.
  • Nov 17, 2021 - Version 1.2.6: Disabled lint prefer_int_literals, it is annoying and also goes against the style of being explicit.
  • Nov 23, 2021 - Version 1.2.7: Improved the docs and updates settings other linters use to newer version of them.
  • Dec 13, 2021 - Version 1.2.8: Disabled lint avoid_final_parameters that is new in Flutter 2.8.0 and Dart 2.15.
  • April 26, 2022 - Version 1.2.9: Added error: deprecated_member_use_from_same_package: ignore
  • May 22, 2022 - Version 2.0.0: Removed library_private_types_in_public_api to kep it enabled via all lint rules.

@MrHallows
Copy link

MrHallows commented Oct 29, 2020

This is extremely helpful. Thank you for sharing!

Also, I've included the following header comment in the base copy:

# All original source credit and thanks to @rydmike (https://gist.github.com/rydmike)
# for his Gist here:
# https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#
# Include `all_lint_rules.dart` file, which lists all available lint rules as
# enabled.
# Source: https://dart-lang.github.io/linter/lints/options/options.html

Very much appreciated! :)

@rydmike
Copy link
Author

rydmike commented Oct 30, 2020

@MrHallows you are welcome and cool if you found it helpful.
Mostly I had just documented my linting setup and my current personal reasoning behind the choices, so I can recall why I set it up the way I did later and also to have a convenient place to copy paste it from for new projects. A friend also asked what kind of setup I'm using and this was a convenient way to share it.

@MrHallows
Copy link

MrHallows commented Oct 31, 2020

@rydmike I figured that was the case (posting it here for personal reasons), but since I came across it and found it useful, I thought I'd let you know and say thank you. Mentioning the header wasn't necessary, I know, but as a fellow programmer/developer, I like to give credit to those who deserve it. Plus, if anyone were to ever come across my code and found that file helpful, they could also be directed back to its source. :)

@rydmike
Copy link
Author

rydmike commented Jul 31, 2021

@MrHallows, since you were here early before and noticed this rule set. I just wanted to drop you a note, letting you know that I wrote a short blog on the Dart linting topic here https://rydmike.com/blog_flutter_linting that also compares used linting rule setup of popular packaged linters. 😃

@Parables
Copy link

Parables commented May 20, 2022

I am sincerely grateful for sharing this. Thanks so much

@rydmike
Copy link
Author

rydmike commented May 20, 2022

@Parables you are welcome. BTW I just updated my blog about this and the Google sheet that compares different linters: https://rydmike.com/blog_flutter_linting

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment