# RydMike LINTER Preferences v2.3.0

# TODO(rydmike): Review and publish this v2.3.0 updated version.

#

# 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.dev/tools/linter-rules/all

#

# For a comparison of all lint rules settings in rule styles listed below, please see this Google

# sheet: https://docs.google.com/spreadsheets/d/1Nc1gFjmCOMubWZD7f2E4fLhWN7LYaOE__tsA7bf2NjA

#

# Versions used for comparison:

# TODO(rydmike): Update the used comparisons to their latest version.

#

# Core v3.0.0 : https://pub.dev/packages/lints

# Recommended v3.0.0 : https://pub.dev/packages/lints

# Flutter Lints v3.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 v2.2.0 : https://pub.dev/packages/lint

# VG Analysis v5.1.0 : https://pub.dev/packages/very_good_analysis

# RydMike v2.1.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/tools/analysis

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 enable conflicting rules and are fixing the conflicts in this file.

# Put it to warning temporarily if you need to 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

# A record literal with exactly one positional field requires a trailing comma.

record_literal_one_positional_no_trailing_comma: error

# Invocation collection methods with arguments of unrelated types.

collection_methods_unrelated_type: warning

# Invocation of equality operator == with references of unrelated types.

unrelated_type_equality_checks: warning

# 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.dev/tools/linter-rules/parameter_assignments.html

#

# Treats 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 you set it to be an error, may

# be a bit problematic if/when 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.dev/tools/linter-rules/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/pasted in code that does things that

# require it, 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.dev/tools/linter-rules/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 and also 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.dev/tools/linter-rules/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.dev/tools/linter-rules/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 devs 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.dev/tools/linter-rules/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 a 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 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 turn off this lint.

#

# Using always_specify_type ON lint like Flutter repo does, makes it easier to reason about

# unfamiliar codebases, especially when you read it on GitHub where the IDE cannot be used to

# look into what type an object is.

#

# 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

# PACKAGE: enabled : Enable rule by commenting it below, do this for PACKAGES.

# APPLICATION: disabled : Disable rule by not commenting the row below, do this for APPS.

# always_specify_types: false

# ALWAYS use package imports for files in lib/.

#

# https://dart.dev/tools/linter-rules/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. Support

# for relative imports has improved in both IDEs. 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 package 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 the 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 enabled : 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.dev/tools/linter-rules/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.dev/tools/linter-rules/avoid_catches_without_on_clauses.html

#

# Using catch clauses without on clauses makes your code prone to encountering unexpected

# errors that won't be thrown (and thus will go unnoticed). However, there are situations

# where we voluntarily want to catch everything, especially as a library.

# See 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.dev/tools/linter-rules/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 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.dev/tools/linter-rules/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 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_final_parameters: false

# AVOID positional boolean parameters.

#

# https://dart.dev/tools/linter-rules/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 disabled : 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.dev/tools/linter-rules/avoid_print.html

#

# Our default is to have this rule enabled.

#

# In example apps you may want to print to the console. You may 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.dev/tools/linter-rules/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 the same as

# default one, mostly to make an unfamiliar API more readable on GitHub.

#

# 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.dev/tools/linter-rules/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 the 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.

# Thus, even if you don't use `always_specify_types`, it is possible to sometimes specify

# them on closures when it improves the 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.dev/tools/linter-rules/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.dev/tools/linter-rules/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

# AVOID using deprecated elements from within the package in which they are declared.

#

# https://dart.dev/tools/linter-rules/deprecated_member_use_from_same_package

#

# Elements that are annotated with @Deprecated should not be referenced from within the

# package in which they are declared.

#

# RydMike: In packages and especially in public packages, it is often useful to deprecate a

# member, but keep it available and functional until the deprecated member is completley

# removed. We thus need to reference it in code and doc comments.

#

# 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

deprecated_member_use_from_same_package: false

# DO reference all public properties in debug method implementations.

#

# https://dart.dev/tools/linter-rules/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 NOT use environment declared variables.

#

# https://dart.dev/tools/linter-rules/do_not_use_environment

#

# Using values derived from the environment at compile-time, creates hidden global state

# and makes applications hard to understand and maintain.

# DON’T use fromEnvironment or hasEnvironment factory constructors.

#

# RydMike: There are appropriate times to use the environment, e.g. in tests and build logic

#

# 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

do_not_use_environment: false

# DO Use Flutter TO-DO format.

#

# https://dart.dev/tools/linter-rules/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.dev/tools/linter-rules/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 the 80-character 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. Ironically, Flutter repo violates this rule, but

# if you do it in a package for pub.dev you get a score deduction. We often disable this rule

# if this is not a package, so we keep it listed here 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 it 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 use super parameter names that match their corresponding super constructor’s

# parameter names.

#

# https://dart.dev/tools/linter-rules/matching_super_parameters

#

# Blocked by issue: https://github.com/dart-lang/language/issues/2509

#

# 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

matching_super_parameters: false

# DO define default behavior outside switch statements.

#

# https://dart.dev/tools/linter-rules/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.dev/tools/linter-rules/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

# CONSIDER omitting obvious type annotations for local variables.

#

# https://dart.dev/tools/linter-rules/omit_obvious_local_variable_types

#

# 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 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 ? : https://pub.dev/packages/lint

# VG Analysis ? : https://pub.dev/packages/very_good_analysis

# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c

# omit_obvious_local_variable_types: false

# PREFER asserts with a message string.

#

# https://dart.dev/tools/linter-rules/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 need fewer 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.dev/tools/linter-rules/prefer_constructors_over_static_methods.html

#

# Dart has named constructors. Static methods in other languages (java) are a workaround to

# not having 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. However, this lint rule

# complained about the above usage too, where we think it makes sense to use a static method.

# This rule currently complains about use cases that in some scenarios are impossible to comply

# with. Maybe this is another issue with this lint rule. We should investigate it further and

# report it if it is an issue. 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.dev/tools/linter-rules/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.dev/tools/linter-rules/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 rule 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.dev/tools/linter-rules/prefer_expression_function_bodies.html

#

# Certainly a 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.dev/tools/linter-rules/prefer_final_parameters.html

#

# Declaring parameters as final when possible is a good practice because it helps

# avoid accidental reassignments.

#

# Certainly a good idea in many cases. There seems to be one "small" false positive issue with it.

# Lint is triggered by final constructor properties, e.g. 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. We had to

# turn OFF this rule due to it.

#

# 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.dev/tools/linter-rules/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.dev/tools/linter-rules/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.dev/tools/linter-rules/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 the 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.dev/tools/linter-rules/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.dev/tools/linter-rules/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

# DO use DecoratedBox when a Container has only a Decoration.

#

# Not used because of this issue https://github.com/dart-lang/linter/issues/3286

#

# 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

use_decorated_box: false