Lint rules and analysis options updated

[navibyte]

Guidelines: Effective Dart

To be considered:
https://github.com/tenhobi/effective_dart

[navibyte]

See also https://rydmike.com/blog >> 2021-01-10 blog post for reference

[navibyte]

See also https://dash-overflow.net/articles/getting_started/

[navibyte]

Updating rules according to blog posts of previous comments.

[navibyte]

New lint rules v1 here. Thanks for blog posts for good hints.

Needed some code changes when implicit-casts: false and implicit-dynamic: false enforced. Some verbosity on some places, but should be more robust then...

These and maybe other changes too coming on next beta version of packages (attributes, datatools, geocore and geodata) later on spring...

# See background
#     https://dash-overflow.net/articles/getting_started/
#     https://rydmike.com/blog => My Flutter Linting Preferences (Jan 10, 2021)
#         Some of comments originated from this blog.

## Include all lint rules 
## (Source => https://dart-lang.github.io/linter/lints/options/options.html)
include: all_lint_rules.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"

  strong-mode:
    # Explained best here => https://dash-overflow.net/articles/getting_started/
    implicit-casts: false

    # Explained best here => https://dash-overflow.net/articles/getting_started/
    implicit-dynamic: false
  
  errors:
    # Otherwise we cause the import of all_lint_rules to warn, because of some 
    # rules conflicts. We explicitly enabled even conflicting rules and are 
    # fixing the conflicts in this file.
    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

linter:
  rules:

[navibyte]

Latest lint rules for BETA release 0.6.0:

# Analysis options / lint rules (2021-04-17)
# 
# Documentation (official)
#     https://dart.dev/guides/language/analysis-options
#     https://dart-lang.github.io/linter/lints/
#
# Other analyzer settings and style guides
#     https://pub.dev/packages/pedantic
#     https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
#     https://dart.dev/guides/language/effective-dart/usage
#
# Getting started
#     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.

## Include all lint rules. 
## (Source => https://dart-lang.github.io/linter/lints/options/options.html)
include: all_lint_rules.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"

  strong-mode:
    # Explained best here => https://dash-overflow.net/articles/getting_started/
    implicit-casts: false

    # Explained best here => https://dash-overflow.net/articles/getting_started/
    implicit-dynamic: false
  
  errors:
    # Otherwise we cause the import of all_lint_rules to warn, because of some 
    # rules conflicts. We explicitly enabled even conflicting rules and are 
    # fixing the conflicts in this file.
    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

linter:

  # Some rules imported from all_lint_rules.yaml disabled here 
  # (with comments sourced https://dart-lang.github.io/linter/lints/<rule>.html)
  rules:
    # "DO separate the control structure expression from its statement."
    # Sometimes it might make sense.
    always_put_control_body_on_new_line: false

    # "DO specify required on named parameter before other named parameters."
    # Good rule, but sometimes it's nice to organize parameters otherwise too.
    always_put_required_named_parameters_first: false

    # "DO specify type annotations."
    # Well, good intention with this rule by Flutter style guide.
    # However see for example: https://github.com/dart-lang/linter/issues/1848
    # Disabled at least for now.
    always_specify_types: false

    # "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 annotating with dynamic when not required."
    # Yes this rule would remove some "dynamic" keywords from code, but as we
    # have "implicit-dynamic" disabled, this rule must be disabled too.
    avoid_annotating_with_dynamic: false
    
    # "AVOID returning null from members whose return type is bool, double, int,
    #  or num."
    # Mostly preferable rule, but there are use cases when some method might
    # need to return unavailibility of bool, double, int or num. For example
    # a value accessor might have "int getInt(String key)" to return non-null
    # integer value, and "int? tryInt(String key)" to return nullable integer
    # value with null meaning "not found" or "could not decode".
    avoid_returning_null: false
    
    # "DO Use Flutter TODO format."
    # Use Dart TODO format instead.
    flutter_style_todos: false

    # "DO define default behavior outside switch statements."
    # Marked experimental rule, not sure why this rule might be important?
    # Using "default" in "switch" statements is quite universal pattern in the
    # art of programming.
    no_default_cases: false
    
    # Marked as unreleased rule.
    # It's easier just to assert something, and if assertion triggers, then code
    # might document what's wrong.
    prefer_asserts_with_message: false
    
    # "PREFER using const for instantiating constant constructors."
    # Pedantic says: "prefer_const_constructors would add a lot of noise to code 
    # now that new is optional."
    # Effective dart says: "Basically, any place where it would be an error to 
    # write new instead of const, Dart 2 allows you to omit the const."
    # Let's disable it here too.
    prefer_const_constructors: false
    
    # "PREFER using const for instantiating list, map and set literals used as 
    #  parameters in immutable class instantiations."
    # Pedantic says: "is too strict, requiring const everywhere adds noise".
    prefer_const_literals_to_create_immutables: false

    # "CONSIDER using => for short members whose body is a single return 
    # statement."
    # Yes for short members, but sometimes this would catch also non-short ones.
    prefer_expression_function_bodies: 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

    # "DO use double quotes where they wouldn't require additional escapes."
    # Instead "prefer_single_quotes".
    prefer_double_quotes: false
    
    # "DO document all public members."
    # Yes for most cases, but sometimes this is too strict.
    public_member_api_docs: false
    
    # "DO sort pub dependencies in pubspec.yaml."
    # Maybe better to organize logically.
    sort_pub_dependencies: false
    
    # "DON'T use final for local variables."
    # This is quite crazy rule. Final in local variables makes code more robust.
    # So "prefer_final_locals."
    unnecessary_final: false

[navibyte]

Implemented on BETA-version 0.6.0.