forked from letsar/flutter_slidable
-
Notifications
You must be signed in to change notification settings - Fork 0
/
analysis_options.yaml
139 lines (101 loc) · 4.59 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
# Enable all rules by default
include: all_lint_rules.yaml
analyzer:
strong-mode:
implicit-casts: false
implicit-dynamic: false
errors:
dead_code: warning
# Otherwise cause the import of all_lint_rules to warn because of some rules conflicts.
# The conflicts are fixed in this file instead, so we can safely ignore the warning.
included_file_warning: ignore
missing_required_param: error
missing_return: error
linter:
rules:
# We prefer having parameters in the same order as fields https://github.com/flutter/flutter/issues/10219
always_put_required_named_parameters_first: false
# Depends on your needs
always_require_non_null_named_parameters: false
# Conflicts with `omit_local_variable_types` and other rules.
# As per Dart guidelines, we want to avoid unnecessary types to make the code
# more readable.
# See https://dart.dev/guides/language/effective-dart/design#avoid-type-annotating-initialized-local-variables
always_specify_types: false
# conflicts with `prefer_relative_imports`
always_use_package_imports: false
# Conflicts with always_specify_types
avoid_annotating_with_dynamic: false
# There are situations where we voluntarily want to catch everything,
# especially as a library.
avoid_catches_without_on_clauses: false
# Only useful when targeting JS runtime
avoid_double_and_int_checks: false
# Improve readbility
avoid_function_literals_in_foreach_calls: false
# Only useful when targeting JS runtime
avoid_js_rounded_ints: false
# We prefer having typedef (discussion in https://github.com/flutter/flutter/pull/16356)
avoid_private_typedef_functions: false
# Useful in a lot of cases
avoid_returning_null: false
# Can be useful to have a more readable code
avoid_types_on_closure_parameters: false
# `as` is not that bad (especially with the upcoming non-nullable types).
# Explicit exceptions is better than implicit exceptions.
avoid_as: false
# Can be difficult to read in some cases
cascade_invocations: false
# Not reliable enough
close_sinks: false
# Blocked on https://github.com/flutter/flutter/issues/20765
comment_references: false
# Not useful for public properties for a constructor
diagnostic_describe_all_properties: false
# This project doesn't use Flutter-style todos
flutter_style_todos: false
# Experimental: Too many false positives: https://github.com/dart-lang/linter/issues/811
invariant_booleans: false
# Can be useful to have a more readable code
join_return_with_assignment: false
# Not useful for comments
lines_longer_than_80_chars: false
# Too many false positives: https://github.com/dart-lang/sdk/issues/34181
literal_only_boolean_expressions: false
# Disabled for now until we have NNBD as it otherwise conflicts with `missing_return`
no_default_cases: false
# Can be useful to have a more readable code
omit_local_variable_types: false
# Too many false positives
one_member_abstracts: false
# Issue: https://github.com/flutter/flutter/issues/5792
only_throw_errors: false
# Issue: https://github.com/dart-lang/language/issues/32
prefer_mixin: false
# Intelissence do the jobs for constructors.
prefer_asserts_with_message: false
# More readable
prefer_relative_imports: false
# Conflicts with `prefer_single_quotes`
# Single quotes are easier to type and don't compromise on readability.
prefer_double_quotes: false
# Conflicts with https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#consider-using--for-short-functions-and-methods
# Not quite suitable for Flutter, which may have a `build` method with a single
# return, but that return is still complex enough that a "body" is worth it.
prefer_expression_function_bodies: false
# False positives
top_level_function_literal_block: false
# We don't want to enforce this rule now.
sort_pub_dependencies: false
# Too many false positives
unawaited_futures: false
# Has false positives: https://github.com/dart-lang/linter/issues/498
unnecessary_lambdas: false
# Has false positives: https://github.com/dart-lang/sdk/issues/34182
use_string_buffers: false
# Has false positives, so we prefer to catch this by code-review
use_to_and_as_if_applicable: false
# Incompatible with `prefer_final_locals`
# Having immutable local variables makes larger functions more predictible
# so we will use `prefer_final_locals` instead.
unnecessary_final: false