analysis_options.yaml

# Analysis options / lint rules (2023-03-14 / "packages edition")
#
# Documentation (official for Dart)
#     https://pub.dev/packages/lints
#     https://dart.dev/guides/language/analysis-options
#     https://dart-lang.github.io/linter/lints/
#
# Documentation (official for Flutter)
#     https://pub.dev/packages/flutter_lints
#
# Getting started (before new official Dart and Flutter lints announced!)
#     https://dash-overflow.net/articles/getting_started/
#         Some of comments originated from this blog.
#     https://rydmike.com/blog => My Flutter Linting Preferences (Jan 10, 2021)
#         Some of comments originated from this blog.
#
# Comparisons of different lints
#     https://twitter.com/RydMike/status/1426310690965532678
#         Updated lint rules comparison (Aug 14, 2021)
#         Notes about "very_good_analysis" 2.3.0+
#
# Applied package
#     https://pub.dev/packages/very_good_analysis
#     4.0.0+
#
# See also
#     https://github.com/VeryGoodOpenSource/very_good_analysis/issues/46
#     https://github.com/navibyte/geospatial/issues/148

include: package:very_good_analysis/analysis_options.yaml

analyzer:
  exclude:
    # Ignore warnings of files generated by json_serializable, built_value etc.
    - "**/*.g.dart"

    # Ignore warnings of files generated by Freezed.
    - "**/*.freezed.dart"

# Some rules that were enabled by "very_good_analysis" disabled here
linter:
  rules:
    # "DO avoid relative imports for files in lib/."
    # What's wrong with relative imports between source code inside lib.
    # So disable this rule. However "avoid_relative_lib_imports" is enabled.
    always_use_package_imports: false

    # "DO use int literals rather than the corresponding double literal."
    # It's better to use 0.0 or 342.0 for doubles than 0 and 342.
    # For example in code setting geospatial coordinates, like latitude and
    # longitude, it feels more natural using double literals always.
    prefer_int_literals: false

    # "DO sort constructor declarations before other members."
    # This rule is very opionated. Sometimes for domain data classes with lot
    # of contructors and named factories, it would be nices to put field members
    # first, then constructors. However for most of other cases the rule might
    # be good.
    # See also discussion on lint: https://github.com/passsy/dart-lint/issues/1
    sort_constructors_first: false

    # "DO sort pub dependencies in pubspec.yaml."
    # Yes do sort most of time, but sometimes better to organize logically.
    # For example first sorted list of packages from external vendors, then
    # next sorted list of custom packages.
    sort_pub_dependencies: false

    # "DO specify required on named parameter before other named parameters."
    # Generally a valid rule, but there are use cases when other order is more
    # logical.
    always_put_required_named_parameters_first: false