2

I want my linter to complain about missing type annotations everywhere except for lambdas, because in my opinion it worsens the code readability with little advantages.

For example those statements should raise a warning/hint:

const s = 'my string'; // Specify type annotation.
foo() => 'foo';        // Missing return type for foo.
List bar() =>          // Specify type annotation.
    ['bar', 'baz'];    // Specify type annotation.

This should not:

<String>['qux', 'quux', 'corge']
    .map((s) => s.toUpperCase());

I thinks those are the relevant rules in my analysis_option.yaml :

analyzer:
  strong-mode:
    implicit-dynamic: false
errors:
    missing_required_param: warning
    missing_return: warning
    [...]

and

linter:
  rules:
    [...]
    - always_specify_types
    [...]

If needed this is the full analysis_option.yaml

# Specify analysis options.
#
# Until there are meta linter rules, each desired lint must be explicitly enabled.
# See: https://github.com/dart-lang/linter/issues/288
#
# For a list of lints, see: http://dart-lang.github.io/linter/lints/
# See the configuration guide for more
# https://github.com/dart-lang/sdk/tree/master/pkg/analyzer#configuring-the-analyzer
#
# There are other similar analysis options files in the flutter repos,
# which should be kept in sync with this file:
#
#   - analysis_options.yaml (this file)
#   - packages/flutter/lib/analysis_options_user.yaml
#   - https://github.com/flutter/plugins/blob/master/analysis_options.yaml
#   - https://github.com/flutter/engine/blob/master/analysis_options.yaml
#
# This file contains the analysis options used by Flutter tools, such as IntelliJ,
# Android Studio, and the `flutter analyze` command.

analyzer:
  strong-mode:
    implicit-dynamic: false
  errors:
    # treat missing required parameters as a warning (not a hint)
    missing_required_param: warning
    # treat missing returns as a warning (not a hint)
    missing_return: warning
    # allow having TODOs in the code
    todo: warning
    # Ignore analyzer hints for updating pubspecs when using Future or
    # Stream and not importing dart:async
    # Please see https://github.com/flutter/flutter/pull/24528 for details.
    sdk_version_async_exported_from_core: ignore
  exclude:
    - "bin/cache/**"
    # the following two are relative to the stocks example and the flutter package respectively
    # see https://github.com/dart-lang/sdk/issues/28463
    - "lib/i18n/stock_messages_*.dart"
    - "lib/src/http/**"

linter:
  rules:
    # these rules are documented on and in the same order as
    # the Dart Lint rules page to make maintenance easier
    # https://github.com/dart-lang/linter/blob/master/example/all.yaml
    - always_declare_return_types
#    - always_put_control_body_on_new_line
    # - always_put_required_named_parameters_first # we prefer having parameters in the same order as fields https://github.com/flutter/flutter/issues/10219
    - always_require_non_null_named_parameters
    - always_specify_types
    - annotate_overrides
    # - avoid_annotating_with_dynamic # conflicts with always_specify_types
    - avoid_as
    - avoid_bool_literals_in_conditional_expressions
    # - avoid_catches_without_on_clauses # we do this commonly
    # - avoid_catching_errors # we do this commonly
    # - avoid_classes_with_only_static_members
    # - avoid_double_and_int_checks # only useful when targeting JS runtime
    - avoid_empty_else
    - avoid_field_initializers_in_const_classes
    - avoid_function_literals_in_foreach_calls
    # - avoid_implementing_value_types # not yet tested
    - avoid_init_to_null
    # - avoid_js_rounded_ints # only useful when targeting JS runtime
    - avoid_null_checks_in_equality_operators
    # - avoid_positional_boolean_parameters # not yet tested
    # - avoid_private_typedef_functions # we prefer having typedef (discussion in https://github.com/flutter/flutter/pull/16356)
    - avoid_relative_lib_imports
    - avoid_return_types_on_setters
    # - avoid_returning_null # there are plenty of valid reasons to return null
    # - avoid_returning_null_for_future # not yet tested
    - avoid_returning_null_for_void
    # - avoid_returning_this # there are plenty of valid reasons to return this
    # - avoid_setters_without_getters # not yet tested
    # - avoid_shadowing_type_parameters # not yet tested
    # - avoid_single_cascade_in_expression_statements # not yet tested
    - avoid_slow_async_io
    - avoid_types_as_parameter_names
    # - avoid_types_on_closure_parameters # conflicts with always_specify_types
    - avoid_unused_constructor_parameters
    - avoid_void_async
    - await_only_futures
    - camel_case_types
    - cancel_subscriptions
    # - cascade_invocations # not yet tested
    # - close_sinks # not reliable enough
    # - comment_references # blocked on https://github.com/flutter/flutter/issues/20765
    # - constant_identifier_names # needs an opt-out https://github.com/dart-lang/linter/issues/204
    - control_flow_in_finally
    # - curly_braces_in_flow_control_structures # not yet tested
    # - diagnostic_describe_all_properties # not yet tested
    - directives_ordering
    - empty_catches
    - empty_constructor_bodies
    - empty_statements
    # - file_names # not yet tested
    - flutter_style_todos
    - hash_and_equals
    - implementation_imports
    # - invariant_booleans # too many false positives: https://github.com/dart-lang/linter/issues/811
    - iterable_contains_unrelated_type
    # - join_return_with_assignment # not yet tested
    - library_names
    - library_prefixes
    # - lines_longer_than_80_chars # not yet tested
    - list_remove_unrelated_type
    # - literal_only_boolean_expressions # too many false positives: https://github.com/dart-lang/sdk/issues/34181
    - no_adjacent_strings_in_list
    - no_duplicate_case_values
    - non_constant_identifier_names
    # - null_closures  # not yet tested
    # - omit_local_variable_types # opposite of always_specify_types
    # - one_member_abstracts # too many false positives
    # - only_throw_errors # https://github.com/flutter/flutter/issues/5792
    - overridden_fields
    - package_api_docs
    - package_names
    - package_prefixed_library_names
    # - parameter_assignments # we do this commonly
    - prefer_adjacent_string_concatenation
    - prefer_asserts_in_initializer_lists
    # - prefer_asserts_with_message # not yet tested
    - prefer_collection_literals
    - prefer_conditional_assignment
    - prefer_const_constructors
    - prefer_const_constructors_in_immutables
    - prefer_const_declarations
    - prefer_const_literals_to_create_immutables
    # - prefer_constructors_over_static_methods # not yet tested
    - prefer_contains
    # - prefer_double_quotes # opposite of prefer_single_quotes
    - prefer_equal_for_default_values
    # - prefer_expression_function_bodies # conflicts with https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#consider-using--for-short-functions-and-methods
    - prefer_final_fields
    # - prefer_final_in_for_each # not yet tested
    - prefer_final_locals
    # - prefer_for_elements_to_map_fromIterable # not yet tested
    - prefer_foreach
    # - prefer_function_declarations_over_variables # not yet tested
    - prefer_generic_function_type_aliases
    # - prefer_if_elements_to_conditional_expressions # not yet tested
    - prefer_if_null_operators
    - prefer_initializing_formals
    - prefer_inlined_adds
    # - prefer_int_literals # not yet tested
    # - prefer_interpolation_to_compose_strings # not yet tested
    - prefer_is_empty
    - prefer_is_not_empty
    - prefer_iterable_whereType
    # - prefer_mixin # https://github.com/dart-lang/language/issues/32
    # - prefer_null_aware_operators # disable until NNBD, see https://github.com/flutter/flutter/pull/32711#issuecomment-492930932
    - prefer_single_quotes
    - prefer_spread_collections
    - prefer_typing_uninitialized_variables
    - prefer_void_to_null
    # - provide_deprecation_message # not yet tested
    # - public_member_api_docs # enabled on a case-by-case basis; see e.g. packages/analysis_options.yaml
    - recursive_getters
    - slash_for_doc_comments
    # - sort_child_properties_last # not yet tested
    - sort_constructors_first
    - sort_pub_dependencies
    - sort_unnamed_constructors_first
    - test_types_in_equals
    - throw_in_finally
    # - type_annotate_public_apis # subset of always_specify_types
    - type_init_formals
    # - unawaited_futures # too many false positives
    # - unnecessary_await_in_return # not yet tested
    - unnecessary_brace_in_string_interps
    - unnecessary_const
    - unnecessary_getters_setters
    # - unnecessary_lambdas # has false positives: https://github.com/dart-lang/linter/issues/498
    - unnecessary_new
    - unnecessary_null_aware_assignments
    - unnecessary_null_in_if_null_operators
    - unnecessary_overrides
    - unnecessary_parenthesis
    - unnecessary_statements
    - unnecessary_this
    - unrelated_type_equality_checks
    # - unsafe_html # not yet tested
    - use_full_hex_values_for_flutter_colors
    # - use_function_type_syntax_for_parameters # not yet tested
    - use_rethrow_when_possible
    # - use_setters_to_change_properties # not yet tested
    # - use_string_buffers # has false positives: https://github.com/dart-lang/sdk/issues/34182
    # - use_to_and_as_if_applicable # has false positives, so we prefer to catch this by code-review
    - valid_regexps
    # - void_checks # not yet tested
Pado
  • 1,497
  • 16
  • 28

1 Answers1

1

You're looking for the avoid_type_checks_on_closure_parameters lint.

From the docs:

AVOID annotating types for function expression parameters.

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.

BAD:

var names = people.map((Person person) => person.name);

GOOD:

var names = people.map((person) => person.name);

EDIT: It looks like there's an open issue for this. If you're hitting this, go and thumbs up the issue and maybe leave a comment since the team takes those into account when prioritizing bug fixes.

Ben Konyi
  • 2,849
  • 12
  • 20
  • 1
    This actually points out my problem: anyway this rule is conflicting with [always_specify_types](https://dart-lang.github.io/linter/lints/always_specify_types.html). If I enable them both the linter will complain for every lambda in my code: `people.map((Person person) => person.name);` will hint not to type annotate lambdas and `var names = people.map((person) => person.name);` will hint to "always specify type annotation" – Pado Dec 31 '19 at 08:56
  • Sorry for the delay. It looks like there's an open issue for this (see the edit). You might want to follow up there to bring it back to the attention of the `dartanalyzer` team. – Ben Konyi Jan 02 '20 at 16:20
  • I think there are plans to improve this. There were related discussions on `strong-mode`, but non-nullable overshadowed many things for several years now already. But now that it's out ... \o/ – Günter Zöchbauer Dec 03 '20 at 09:38