-
Notifications
You must be signed in to change notification settings - Fork 16
/
analysis_options.yaml
211 lines (155 loc) · 8.36 KB
/
analysis_options.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
linter:
rules:
- avoid_empty_else
# When mixing relative and absolute imports it’s possible to create confusion where the same member gets imported in two different ways. An easy way to avoid that is to ensure you have no relative imports that include lib/ in their paths.
- avoid_relative_lib_imports
# AVOID using a parameter name that is the same as an existing type.
- avoid_types_as_parameter_names
# AVOID using await on anything which is not a future.
# Await is allowed on the types: Future<X>, FutureOr<X>, Future<X>?, FutureOr<X>? and dynamic.
# Further, using await null is specifically allowed as a way to introduce a microtask delay.
- await_only_futures
# DO name extensions using UpperCamelCase. Extensions should capitalize the first letter of each word (including the first word), and use no separators.
- camel_case_extensions
# DO name types using UpperCamelCase.
# Classes and typedefs should capitalize the first letter of each word (including the first word), and use no separators.
- camel_case_types
# DON’T invoke certain collection method with an argument with an unrelated type.
- collection_methods_unrelated_type
- curly_braces_in_flow_control_structures
# DO depend on referenced packages. When importing a package, add a dependency on it to the pubspec.
- depend_on_referenced_packages
# In general, empty catch blocks should be avoided.
# In cases where they are intended, a comment should be provided to explain why exceptions are being caught and suppressed.
# Alternatively, the exception identifier can be named with underscores (e.g., _) to indicate that we intend to skip it.
- empty_catches
# DO name source files using lowercase_with_underscores
- file_names
# Every object in Dart has a hashCode. Both the == operator and the hashCode property of objects must be consistent in order for a common hash map implementation to function properly.
# Thus, when overriding ==, the hashCode should also be overridden to maintain consistency. Similarly, if hashCode is overridden, == should be also.
- hash_and_equals
# Don't use more than one case with same value.
- no_duplicate_case_values
# Name non-constant identifiers using lowerCamelCase.
- non_constant_identifier_names
# Don't use null check on a potentially nullable type parameter.
- null_check_on_nullable_type_parameter
# Prefix library names with the package name and a dot-separated path.
- package_prefixed_library_names
# Use isEmpty for Iterables and Maps.
# Use isNotEmpty for Iterables and Maps.
- prefer_is_empty
- prefer_is_not_empty
# Prefer to use whereType on iterable.
- prefer_iterable_whereType
# PREFER specifying a type annotation for uninitialized variables and fields.
- prefer_typing_uninitialized_variables
# DO Use secure urls in pubspec.yaml.
# Use https instead of http or git
- secure_pubspec_urls
# If you meant to test if the object has type Foo, instead write Foo _.
- type_literal_in_constant_pattern
# Don't override a method to do a super method invocation with the same parameters.
- unnecessary_overrides
# Comparing references of a type where neither is a subtype of the other most likely will return false and might not reflect programmer’s intent.
- unrelated_type_equality_checks
# DO use strings in `part of` directives.
- use_string_in_part_of_directives
# Use valid regular expression syntax
- valid_regexps
# DON'T assign to void
- void_checks
# Annotate overridden members
- annotate_overrides
# AVOID using forEach with a function literal
# The for loop enables a developer to be clear and explicit as to their intent.
# A return in the body of the for loop returns from the body of the function, where as a return in the body of the forEach closure only returns a value for that iteration of the forEach.
# The body of a for loop can contain awaits, while the closure body of a forEach cannot.
- avoid_function_literals_in_foreach_calls
# Adding = null is redundant and unneeded
- avoid_init_to_null
# DON’T check for null in custom == operators
# As null is a special value, no instance of any class (other than Null) can be equivalent to it. Thus, it is redundant to check whether the other instance is null.
- avoid_null_checks_in_equality_operators
# Don't rename parameters of overridden methods.
- avoid_renaming_method_parameters
- avoid_return_types_on_setters
- avoid_returning_null_for_void
- avoid_single_cascade_in_expression_statements
- constant_identifier_names
# AVOID control flow leaving finally blocks. Using control flow in finally blocks will inevitably cause unexpected behavior that is hard to debug.
- control_flow_in_finally
- empty_constructor_bodies
- empty_statements
# Define case clauses for all constants in enum-like classes.
- exhaustive_cases
# DON’T import implementation files from another package.
- implementation_imports
# Name libraries using lowercase_with_underscores
- library_names
# Use lowercase_with_underscores when specifying a library prefix.
- library_prefixes
- no_leading_underscores_for_library_prefixes
- no_leading_underscores_for_local_identifiers
# DON’T pass null as an argument where a closure is expected.
# Often a closure that is passed to a method will only be called conditionally, so that tests and “happy path” production calls do not reveal that null will result in an exception being thrown.
- null_closures
# DON’T override fields.
# Overriding fields is almost always done unintentionally. Regardless, it is a bad practice to do so.
- overridden_fields
# Use lowercase_with_underscores for package names.
- package_names
# DO use adjacent strings to concatenate string literals.
- prefer_adjacent_string_concatenation
# DO use collection literals when possible.
- prefer_collection_literals
# Prefer using ??= over testing for null
- prefer_conditional_assignment
# Use contains for List and String instances.
- prefer_contains
# Private field could be final
- prefer_final_fields
# Prefer 'for' elements when building maps from iterables.
- prefer_for_elements_to_map_fromIterable
# DO use a function declaration to bind a function to a name.
# As Dart allows local function declarations, it is a good practice to use them in the place of function literals.
- prefer_function_declarations_over_variables
# PREFER using if null operators instead of null checks in conditional expressions.
- prefer_if_null_operators
# DO use initializing formals when possible.
# Using initializing formals when possible makes your code more terse.
- prefer_initializing_formals
# Inline list item declarations where possible.
- prefer_inlined_adds
- prefer_interpolation_to_compose_strings
# Prefer is! operator.
- prefer_is_not_operator
# PREFER using null aware operators instead of null checks in conditional expressions.
- prefer_null_aware_operators
# Use spread collections when possible.
# Collection literals are excellent when you want to create a new collection out of individual items. But, when existing items are already stored in another collection, spread collection syntax leads to simpler code.
- prefer_spread_collections
# DON’T create recursive getters.
# Recursive getters are getters which return themselves as a value. This is usually a typo.
- recursive_getters
# Prefer using /// for doc comments.
- slash_for_doc_comments
# DON’T type annotate initializing formals.
- type_init_formals
# Avoid using braces in interpolation when not needed.
- 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
- unnecessary_to_list_in_spreads
- use_function_type_syntax_for_parameters
- use_rethrow_when_possible
- use_super_parameters