Apply very_good_analysis 2.3.0+ lint rules

[navispatial]

BETA 0.7.0 applied Official Dart lint rules applied with recommend set #2. Before that there was some custom lint rules.

However as @rydmike has demonstrated the official rules (even "recommend" set) is not actually very strict. So missing some good rules that make code better and more consistent.

very_good_analysis starting from version 2.3.0 seems to be quite good option to use as lint rules.

Official lint rules with "recommend" set has 74 rules applied, as very_good_analysis has 153 rules with quite good coverage.

These very_good_analysis rules need to be tested to see how they work:

Update pubspec.yaml:

dev_dependencies:
  very_good_analysis: ^2.3.0

And analysis_options.yaml:

include: package:very_good_analysis/analysis_options.yaml

This shall use analysis_options.2.3.0.yaml (link to github repo) from very_good_analysis. It seems to have strong mode well defined too along with linter rules (not listed below, see the repo link):

analyzer:
  strong-mode:
    implicit-casts: false
    implicit-dynamic: false

  errors:
    close_sinks: ignore
    missing_required_param: error
    missing_return: error

  exclude:
    - test/.test_coverage.dart
    - lib/generated_plugin_registrant.dart

[navispatial]

First tests on very_good_analysis v. 2.3.0 seem positive, code needs some modifications to pass all rules, but nothing impossible.

For following rules not agreeing with very_good_analysis, so this shall be disabled on analysis_options.yaml

# Some rules imported from "very_good_analysis" disabled
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.
    prefer_int_literals: false

Also some other shall be disabled case by case on a file or code line scope.

[navispatial]

Also following to be disabled from custom analysis_options.yaml:

    # "DO sort pub dependencies in pubspec.yaml."
    # Yes do sort most of time, but sometimes better to organize logically.
    sort_pub_dependencies: false    

[navispatial]

analysis_options.yaml after applying very_good_analysis on all code on this repository:

# Analysis options / lint rules (2021-08-18)
# 
# 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

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"

  language:
    # See => https://github.com/dart-lang/language/blob/master/resources/type-system/strict-raw-types.md
    strict-raw-types: true

# Note this are enabled already by "very_good_analysis" but good to note here:
#  strong-mode:
#    implicit-casts: false
#    implicit-dynamic: false

# 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 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    

[navispatial]

Improving lint rules usage and code quality...

Currently following rules considered such that no reason to keep them enabled even if very_good_analysis 2.3.0 enables them:

# 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

    # "AVOID returning null from members whose return type is bool, double, int, 
    #  or num."
    # As dart-lint is commenting, this rule has lost it's meaning after proper
    # null-safety support on Dart. And there are valid cases for returning nulls
    # even for primitive types.
    avoid_returning_null: 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    

[navispatial]

Previous comment was about packages.

For app code, also following should be disabled:

    # "DO document all public members."
    # Not a library package to be published on pub.dev, so not so strict.
    public_member_api_docs: false

[navispatial]

Implemented in Release version 0.8.0