-
Notifications
You must be signed in to change notification settings - Fork 26
Feature/setup-linter-rules #51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
ImportantSome of the properties in analysis_options.yaml are starting as comments. If the property starts with
|
@@ -1,5 +1,274 @@ | |||
include: package:lints/recommended.yaml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't wanna remove this. Can't dart_code_metrics
work with this? Please remove metrics if it can't. I don't wanna make this change if it can't. I'd prefer standard recommended rules always.
linter: | ||
rules: | ||
constant_identifier_names: false | ||
# Const rules. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of these rules are already true by default in recommended lints package. We can avoid stating them here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Sanlovty Did you remove rules which are set by default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, every one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, it seems that a lot of rules explicitly mentioned here are already included by lints
package. Here's a list of all the rules included by lints
package so that you can compare:
linter:
rules:
- avoid_empty_else
- avoid_relative_lib_imports
- avoid_shadowing_type_parameters
- avoid_types_as_parameter_names
- await_only_futures
- camel_case_extensions
- camel_case_types
- curly_braces_in_flow_control_structures
- depend_on_referenced_packages
- empty_catches
- file_names
- hash_and_equals
- iterable_contains_unrelated_type
- list_remove_unrelated_type
- no_duplicate_case_values
- non_constant_identifier_names
- null_check_on_nullable_type_parameter
- package_prefixed_library_names
- prefer_generic_function_type_aliases
- prefer_is_empty
- prefer_is_not_empty
- prefer_iterable_whereType
- prefer_typing_uninitialized_variables
- provide_deprecation_message
- unnecessary_overrides
- unrelated_type_equality_checks
- valid_regexps
- void_checks
- always_require_non_null_named_parameters
- annotate_overrides
- avoid_function_literals_in_foreach_calls
- avoid_init_to_null
- avoid_null_checks_in_equality_operators
- avoid_renaming_method_parameters
- avoid_return_types_on_setters
- avoid_returning_null_for_void
- avoid_single_cascade_in_expression_statements
- constant_identifier_names
- control_flow_in_finally
- empty_constructor_bodies
- empty_statements
- exhaustive_cases
- implementation_imports
- library_names
- library_prefixes
- library_private_types_in_public_api
- no_leading_underscores_for_library_prefixes
- no_leading_underscores_for_local_identifiers
- null_closures
- overridden_fields
- package_names
- prefer_adjacent_string_concatenation
- prefer_collection_literals
- prefer_conditional_assignment
- prefer_contains
- prefer_equal_for_default_values
- prefer_final_fields
- prefer_for_elements_to_map_fromIterable
- prefer_function_declarations_over_variables
- prefer_if_null_operators
- prefer_initializing_formals
- prefer_inlined_adds
- prefer_interpolation_to_compose_strings
- prefer_is_not_operator
- prefer_null_aware_operators
- prefer_spread_collections
- prefer_void_to_null
- recursive_getters
- slash_for_doc_comments
- type_init_formals
- unnecessary_brace_in_string_interps
- unnecessary_const
- unnecessary_constructor_name
- unnecessary_getters_setters
- unnecessary_late
- unnecessary_new
- unnecessary_null_aware_assignments
- unnecessary_null_in_if_null_operators
- unnecessary_nullable_for_final_variable_declarations
- unnecessary_string_escapes
- unnecessary_string_interpolations
- unnecessary_this
- use_function_type_syntax_for_parameters
- use_rethrow_when_possible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll check this later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
Codecov Report
@@ Coverage Diff @@
## main #51 +/- ##
==========================================
+ Coverage 68.30% 69.04% +0.74%
==========================================
Files 13 13
Lines 489 491 +2
==========================================
+ Hits 334 339 +5
+ Misses 155 152 -3
Continue to review full report at Codecov.
|
Description of the Changes
Adding dart_code_metrics, setting
analysis_options.yaml
by adding analyzer rules and linter rules.Benefits
The standard of formatting is good even by the fact that it is. Linter will help improve the quality of the code, leading it to the best practices, reducing the number of formatting errors that could cause consequences.
Possible Drawbacks
Not found.
Verification Process
dart analyze
anddart format . --fix
Applicable Issues
None