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
#
# 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:
    - "**/*.config.dart"
    - "**/*.g.dart"
    - "**/*.gr.dart"
    - "**/*.freezed.dart"
    - "**/*.mocks.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

    # Problem with freezed package
    # https://github.com/rrousselGit/freezed/issues/488
    invalid_annotation_target: 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

    # DON’T use wildcard parameters or variables.
    # 
    # Wildcard parameters and local variables (e.g. underscore-only names like _, __, ___, etc.) 
    # will become non-binding in a future version of the Dart language. Any existing code 
    # that uses wildcard parameters or variables will break. In anticipation of this change, 
    # and to make adoption easier, this lint disallows wildcard and variable parameter uses.
    #
    # Personal preference
    no_wildcard_variable_uses: 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

    # DO sort pub dependencies in pubspec.yaml.
    #
    # Personal preference, prefer grouping by feature
    sort_pub_dependencies: 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