-
Notifications
You must be signed in to change notification settings - Fork 7
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
add additional lints to dart_flutter_team_lints #167
Changes from 5 commits
a49e68f
fc35292
64192c8
e90352e
05b02db
a3b5918
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18,13 +18,15 @@ include: package:lints/recommended.yaml | |
analyzer: | ||
language: | ||
strict-casts: true | ||
strict-inference: true | ||
|
||
linter: | ||
rules: | ||
# consistency | ||
- avoid_empty_else | ||
- avoid_shadowing_type_parameters | ||
- avoid_types_as_parameter_names | ||
- avoid_unused_constructor_parameters | ||
- camel_case_extensions | ||
- combinators_ordering | ||
- curly_braces_in_flow_control_structures | ||
|
@@ -35,8 +37,10 @@ linter: | |
- lines_longer_than_80_chars | ||
- omit_local_variable_types | ||
- prefer_asserts_in_initializer_lists | ||
- prefer_const_constructors | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @sigmundch - is there any risk of degrading IPL or any other negative impacts by making too many values There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't have a strong opinion with this lint, but note that we do have it enabled in 22 of 29 sampled dart-lang packages, and flutter turns this lint on. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Indeed, it moves initialization of each of those values to be done eagerly during the IPL as you noted (as opposed to being lazy or on-demand at the time you need it.). The question comes down to how many constants we are talking about. If it's just a handful of them, it's fine, but if all the sudden this will increase the total number of constants by 2x, that's more concerning. cc @rakudrama, although he is about to be on PTO for a while. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It will degrade IPL but a few small constants will not make much difference. It is really hard to give advice here since it depends a lot on the number and qualities of the constants. A few moderate sized class constants would be fine, unless one of their fields were initialized with, say, a gargantuan map. I'd like to make dart2js be smarter about the impact of larger constants on IPL (e.g. dart-lang/sdk#32943) but I don't think it will ever be zero. I would say go ahead since constant widgets, being identical each frame, help the flutter framework more efficiently detect parts of the widget tree that are invariant. It can translate to better frame rate. |
||
- prefer_generic_function_type_aliases | ||
- prefer_is_empty | ||
- prefer_relative_imports | ||
- prefer_single_quotes | ||
- prefer_typing_uninitialized_variables | ||
- sort_pub_dependencies | ||
|
@@ -47,18 +51,22 @@ linter: | |
- unnecessary_statements | ||
- use_is_even_rather_than_modulo | ||
- use_string_in_part_of_directives | ||
- use_super_parameters | ||
|
||
# correctness | ||
- always_declare_return_types | ||
- avoid_catching_errors | ||
- avoid_dynamic_calls | ||
- await_only_futures | ||
- cancel_subscriptions | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think this lint is reliable enough - there are false positives. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. sgtm - will remove |
||
- collection_methods_unrelated_type | ||
- comment_references | ||
- dangling_library_doc_comments | ||
- hash_and_equals | ||
- implicit_call_tearoffs | ||
- no_duplicate_case_values | ||
- only_throw_errors | ||
- test_types_in_equals | ||
- throw_in_finally | ||
- type_annotate_public_apis | ||
- unawaited_futures | ||
|
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.
This one could lead to forced breaking API changes if a constructor parameter stops being used but is still passed by callers.
I don't know if it would ever occur that a constructor argument starts being ignored and it's not already a breaking behavior change, but I'm a little paranoid about lints that could suggest breaking API changes because an author applying a quick fix is less likely to consider impact on usages than an author manually changing arguments...
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, people will feel the need to address these issues, and will assume that the lint is telling them the right thing to do.