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

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.