RydMike lints v2.2.0 - Personal preferences and starting point for Dart & Flutter linter rules setup.

analysis_options.yaml

# RydMike LINTER Preferences v2.2.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.dev/tools/linter-rules/all
#
# Also available as direct yaml file call all.yaml here:
# https://raw.githubusercontent.com/dart-lang/sdk/refs/heads/main/pkg/linter/example/all.yaml
#
# 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:
#
# 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

    # 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

@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.

@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. :)

@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. 😃

I am sincerely grateful for sharing this. Thanks so much

@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

Where can i find the 2.1.0 changes? To all_lint_rules and analysis_options.

Hi @Braj65, in the blog post it is mentioned that:

You can get the latest official and always up-to-date version of all lint rules here, grab its content and put it in a file called all_lint_rules.yaml.

Where "here", links to https://dart-lang.github.io/linter/lints/options/options.html, a least of latest lints that is maintained by the Dart team.

The same link is also mentioned on row 7 in the above analysis_options.yaml. hope this helps. 😃

Thanks @rydmike for answering. Actually my question was based on below screenshot-

On Oct 7 2022, you have added 18 new lint rules to your lint style. What are only those 18 lint rules. Where can i see them as a changelog? I wanted to update only those 18 in my lint rules sheet.

Ah, OK version 2.0.0 of my analysis_options.yaml now, compared to how it was Sep 10, 2021, has not actually changed much, the net is that I have disabled 3 rules that did not fit my style:

1. prefer_final_parameters, this has warning instead via parameter_assignments: warning.
2. prefer_int_literals
3. avoid_final_parameters

So that would actually be -3 lints, however yes the change to +18 lints actually means that the Dart team has added a bunch of new lints since September 10, 2021, they also removed some deprecated ones from it.

What I actually do when I update the all_lint_rules.yaml content first time to a project, is look at the Git diff after copy/pasting it into an existing project. I then look at the added rules the diff shows, check what they do in Dart docs. If I like it, mostly I do, I'm done, it is now in use. If I disagree with it, then I update the above analysis_options.yaml add a disable for it, and document why I did not use it, and what other packages do with it (I'm not so good at keeping that up to date though, it may be snapshot of how it was when I disabled the rule).

As for which rules Dart team has actually added to the linter over time, since Sep 10, 2021. I don't really track that. I tried finding a change log of it in Dart docs, but could not find it. Perhaps via their doc commits?

One way to see it could be to check the Community all lint rules packages and how it has changed https://pub.dev/packages/all_lint_rules_community/changelog, but I did not get +18 via it, it starts a bit after that.

So maybe via FlexColorScheme all_lints_rules commit: https://github.com/rydmike/flex_color_scheme/commits/flutter-master/all_lint_rules.yaml

1. depend_on_referenced_packages
2. eol_at_end_of_file
3. noop_primitive_operations
4. prefer_final_parameters
5. unnecessary_constructor_name
6. use_test_throws_matchers
7. avoid_final_parameters
8. conditional_uri_does_not_exist
9. no_leading_underscores_for_library_prefixes
10. no_leading_underscores_for_local_identifiers
11. secure_pubspec_urls
12. sized_box_shrink_expand
13. use_decorated_box
14. unnecessary_late
15. use_colored_box
16. use_enums
17. use_super_parameters
18. collection_methods_unrelated_type
19. combinators_ordering
20. discarded_futures
21. unnecessary_null_aware_operator_on_extension_on_nullable
22. unnecessary_to_list_in_spreadsunreachable_from_main
23. use_string_in_part_of_directives

My net in the same time was -3 by disabling the above mentioned 3 ones, so that nets 20.

In the same time Dart team has removed these deprecated lints from all lint rules:

1. invariant_booleans

Hmm... only one? Seems like 1 is missing, as that would make net total +19 since then, instead of +18.

There might also be discrepancy in my Google sheet that lists all lints, or it could have been in my active rule count in version from Sep 10, 2021. I will double check later.

Thanks @Braj65 for making me dig into this 👍

Thanks @rydmike Always look forward for the lint rules you include/exclude.

Really helpful as I was looking for which lints I should use in my app but you elaborated everything in one place which makes it so easy to see the reasoning, use case, demerits and false positives behind each lint. Thank you.

Also, love your work on packages making working with colours easy in a flutter project ✨.

Thanks!!
It helped me a lot.
Especially, the spreadsheet you created was very helpful.
Through my own deep analysis, I made my version.

https://gist.github.com/KKimj/0785694a8d96ee635ff1353221f18163

Have a nice day!

@KKimj glad if it was helpful.

I always find it interesting and nice when devs find their way all the way here and drop a comment.

Totally intended to be used as a base for your own lint preferences setup and modified however you like it 😄 👍

I should update the comparison article and spreadsheet, however there is new version in about one month coming out of Flutter and I think I will wait until then. Bunch of new lint rules on the way to stable as well.