Strict Flutter lint rules

analysis_options.yaml

# Check https://dart-lang.github.io/linter/lints/ for lint rules documentation
# Update from http://dart-lang.github.io/linter/lints/options/options.html

analyzer:
  errors:
    missing_required_param: error
    missing_return: error
    todo: ignore
  language:
    strict-inference: true
    strict-raw-types: true
    
linter:
  rules:
    - always_declare_return_types
    - always_put_control_body_on_new_line
    # - always_put_required_named_parameters_first # not crucial and we do it all around
    - always_require_non_null_named_parameters
    # - always_specify_types # we use type inference
    - annotate_overrides
    # - avoid_annotating_with_dynamic # we want to be explicit with dynamic
    - avoid_as
    - avoid_bool_literals_in_conditional_expressions
    # - avoid_catches_without_on_clauses # we catch both Exceptions and Errors
    - avoid_catching_errors
    - avoid_classes_with_only_static_members
    - avoid_double_and_int_checks
    - avoid_empty_else
    - avoid_equals_and_hash_code_on_mutable_classes
    - avoid_escaping_inner_quotes
    - avoid_field_initializers_in_const_classes
    - avoid_function_literals_in_foreach_calls
    - avoid_implementing_value_types
    - avoid_init_to_null
    - avoid_js_rounded_ints
    - avoid_null_checks_in_equality_operators
    - avoid_positional_boolean_parameters
    - avoid_print
    - avoid_private_typedef_functions
    - avoid_redundant_argument_values
    - avoid_relative_lib_imports
    - avoid_renaming_method_parameters
    - avoid_return_types_on_setters
    # - avoid_returning_null # we do this commonly
    - avoid_returning_null_for_future
    - avoid_returning_null_for_void
    - avoid_returning_this
    - avoid_setters_without_getters
    - avoid_shadowing_type_parameters
    - avoid_single_cascade_in_expression_statements
    - avoid_slow_async_io
    - avoid_types_as_parameter_names
    # - avoid_types_on_closure_parameters # conflicts with always_specify_types
    - avoid_unnecessary_containers
    - avoid_unused_constructor_parameters
    - avoid_void_async
    - avoid_web_libraries_in_flutter
    - await_only_futures
    - camel_case_extensions
    - camel_case_types
    - cancel_subscriptions
    - cascade_invocations
    - close_sinks
    - comment_references
    # - constant_identifier_names # we are using those all around
    - control_flow_in_finally
    - curly_braces_in_flow_control_structures
    # - diagnostic_describe_all_properties # nice to have for libs but overkill for applications
    - directives_ordering
    - empty_catches
    - empty_constructor_bodies
    - empty_statements
    - file_names
    # - flutter_style_todos # don't need those for now
    - hash_and_equals
    - implementation_imports
    - invariant_booleans
    - iterable_contains_unrelated_type
    - join_return_with_assignment
    - leading_newlines_in_multiline_strings
    - library_names
    - library_prefixes
    # - lines_longer_than_80_chars # we use it when temporarily adding strings before translations
    - list_remove_unrelated_type
    - literal_only_boolean_expressions
    - missing_whitespace_between_adjacent_strings
    - no_adjacent_strings_in_list
    - no_duplicate_case_values
    - no_logic_in_create_state
    - no_runtimeType_toString
    - non_constant_identifier_names
    - null_closures
    # - omit_local_variable_types # opposite of always_specify_types
    - one_member_abstracts
    - only_throw_errors
    - 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 # we do this commonly
    - 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
    - prefer_contains
    # - prefer_double_quotes We use 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
    - prefer_final_locals
    - prefer_for_elements_to_map_fromIterable
    - prefer_foreach
    - prefer_function_declarations_over_variables
    - prefer_generic_function_type_aliases
    - prefer_if_elements_to_conditional_expressions
    - prefer_if_null_operators
    - prefer_initializing_formals
    - prefer_inlined_adds
    - prefer_int_literals
    - prefer_interpolation_to_compose_strings
    - prefer_is_empty
    - prefer_is_not_empty
    - prefer_is_not_operator
    - prefer_iterable_whereType
    - prefer_mixin
    - prefer_null_aware_operators
    # - prefer_relative_imports # we do not use relative imports
    - prefer_single_quotes
    - prefer_spread_collections
    - prefer_typing_uninitialized_variables
    - prefer_void_to_null
    - provide_deprecation_message
    # - public_member_api_docs # do not use for an application, only a library
    - recursive_getters
    - slash_for_doc_comments
    - sort_child_properties_last
    - 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
    - unnecessary_await_in_return
    - unnecessary_brace_in_string_interps
    - unnecessary_const
    # - unnecessary_final # having finals is the preferred approach
    - unnecessary_getters_setters
    - unnecessary_lambdas
    - unnecessary_new
    - unnecessary_null_aware_assignments
    - unnecessary_null_in_if_null_operators
    - unnecessary_overrides
    - unnecessary_parenthesis
    - unnecessary_raw_strings
    - unnecessary_statements
    - unnecessary_string_escapes
    - unnecessary_string_interpolations
    - unnecessary_this
    - unrelated_type_equality_checks
    - unsafe_html
    - use_full_hex_values_for_flutter_colors
    - use_function_type_syntax_for_parameters
    - use_key_in_widget_constructors
    - use_raw_strings
    - use_rethrow_when_possible
    - use_setters_to_change_properties
    - use_string_buffers
    - use_to_and_as_if_applicable
    - valid_regexps
    - void_checks

What does that language mapping do? @tomaszpolanski

@ItsAdityaKSingh Which line are you referring to?

The language section under analyzer!

I know that these ensure that code specifies generic type arguments and make sure that code is maintainable with improved performance. But what actually do they and should we use it for any flutter project?

You can find the explanations for them here:
https://github.com/dart-lang/language/blob/master/resources/type-system/strict-inference.md
https://github.com/dart-lang/language/blob/master/resources/type-system/strict-raw-types.md

Thanks a lot! You rock 💯

@tomaszpolanski is there any way to enforce documentation ? Like any option or plugins etc that makes sure that files are properly documented ?

@literalEval How about this one? https://dart-lang.github.io/linter/lints/public_member_api_docs.html

Will this show a warning/error if something is not documented ? @tomaszpolanski

It should, just try it

@tomaszpolanski I tried it, but it has some issues. Like it asks for documentation for even the class constructors :( and also, isn't applicable to private fields. Is their any fix for these ? Can you please help ?

Yes, this is only for public class members, therefore public constructors as well. I do not know of any alternative for linters for private fields

Okay. Thanks a lot @tomaszpolanski :)
Do you, by any chance, know how to proceed to make a custom linter that does so ?

It is possible to make a 'linter' that scans your code with https://pub.dev/packages/custom_lint
But this wont work with dart analyzer. The official custom linters are not yet available to my knowledge

Thanks. I will try that package and let you know.