-
-
Notifications
You must be signed in to change notification settings - Fork 40
/
analysis_options.yaml
850 lines (813 loc) · 48 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
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
# RydMike LINTER Preferences v2.0.1
#
# Get this file here: https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#
# We include and activate all lint rules, later below we disable the not used or desired ones.
# You can find a list of all lint rules to put in your all_lint_rules.yaml file here:
# https://dart-lang.github.io/linter/lints/options/options.html
#
# For a full comparison of all lint rules settings in rule styles listed below, please see this
# sheet: https://docs.google.com/spreadsheets/d/1Nc1gFjmCOMubWZD7f2E4fLhWN7LYaOE__tsA7bf2NjA
#
# The version used for comparing setting with other linters for the settings
# that are turned OFF here, or have a quick placeholder for turning it OFF, are
# as follows:
#
# Core v2.1.0 : https://pub.dev/packages/lints
# Recommended v2.0.0 : https://pub.dev/packages/lints
# Flutter Lints v2.1.0 : https://pub.dev/packages/flutter_lints
# Pedantic v1.11.1 : https://pub.dev/packages/pedantic
# Effective Dart v1.3.2 : https://pub.dev/packages/effective_dart
# Flutter repo master : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint v1.8.2 : https://pub.dev/packages/lint
# VG Analysis v3.0.0 : https://pub.dev/packages/very_good_analysis
# RydMike v2.0.1 : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#
include: all_lint_rules.yaml
analyzer:
exclude:
- "**/*.g.dart"
- "**/*.freezed.dart"
- "test/.test_coverage.dart"
- "bin/cache/**"
- "lib/generated_plugin_registrant.dart"
# For more information see:
# https://dart.dev/guides/language/analysis-options#enabling-additional-type-checks
language:
strict-casts: true
strict-inference: true
strict-raw-types: true
errors:
# Without ignore here, we cause import of all_lint_rules to warn, because some rules conflict.
# We explicitly enabled even conflicting rules and are fixing the conflicts in this file.
# Put it to warning temporarily if you need to troubleshoot lint rule settings.
included_file_warning: ignore
# Treat missing required parameters as an error, not as a hint or a warning.
missing_required_param: error
# Treat missing returns as an error, not as a hint or a warning.
missing_return: error
# Allow self-reference to deprecated members. This is done because otherwise we have
# to annotate every member in every test, assert, etc. when we deprecate something.
deprecated_member_use_from_same_package: ignore
# DON'T assign new values to parameters of methods or functions.
#
# https://dart-lang.github.io/linter/lints/parameter_assignments.html
#
# Treats assigning new values to a parameter as a warning. We would almost like to set this
# to an error. However, this warning rule, or even more so if you set it to be an error, may
# be a bit problematic if/when you include other code directly that does it a lot.
# It does, however, make code safer when this cannot be done without involving
# an extra local variable for clarity and safety. Enabling this error, even as just a warning,
# does get in the way a bit if all you want to do is a null to default value release runtime
# safety/fallback assignment. For that use case, you have to add a local rule override. With
# null-safety, the need for this kind of null check and re-assignment to default if null,
# is rarely needed. Considering the comment in:
# https://dart-lang.github.io/linter/lints/parameter_assignments.html:
# "Assigning new values to parameters is generally a bad practice unless an operator
# such as ??= is used. Otherwise, arbitrarily reassigning parameters is usually a mistake."
# One might even think the rule would allow using the ??= operator, but it does not. For now,
# we keep this lint as warning and overriding locally with:
#
# When we need it for the ??= operator, or some copy/pasted in code that does things that
# require it, that we don't want to deal with fixing at the moment.
parameter_assignments: warning
# Allow having TODOs in the code.
todo: ignore
# LINTER Preferences
#
# Explicitly disable only the rules we do not want.
linter:
rules:
# ALWAYS separate the control structure expression from its statement.
#
# https://dart-lang.github.io/linter/lints/always_put_control_body_on_new_line.html
#
# This sometimes makes things more unclear when one line is enough. Also, single line if:s are
# fine and also recommended in Effective Dart "DO format your code using dartfmt".
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
always_put_control_body_on_new_line: false
# ALWAYS specify @required on named parameter before other named parameters.
#
# https://dart-lang.github.io/linter/lints/always_put_required_named_parameters_first.html
#
# Conflicts with the convention used by Flutter, which puts `Key key` first
# and `@required Widget child` last.
#
# Other known linters use:
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
always_put_required_named_parameters_first: false
# ALWAYS specify type annotations.
#
# https://dart-lang.github.io/linter/lints/always_specify_types.html
#
# Avoid var when specifying that a type is unknown and short-hands that elude type annotations. Use
# dynamic if you are being explicit that the type is unknown. Use Object if you are being explicit
# that you want an object that implements == and hashCode.
# The linter rule link above states this rule is from the Flutter style guide.
#
# This makes most code intent very explicit, sometimes this may help you
# reason about unfamiliar libs, but it might get tedious when dealing with very familiar ones.
# For devs used to more relaxed or no type declaration, it is probably the other way around.
# This rule is, of course, also in conflict with some other lint rules. Most notably, it
# violates Effective Dart "AVOID type annotating initialized local variables".
# https://dart-lang.github.io/linter/lints/omit_local_variable_types.html
# Which we find to be a strange rule, the package lint agrees with the statement that
# "Types for local variables may improve readability" and keeps that avoid rule disabled.
#
# Turning always_specify_types lint rule on in a project at a later stage is very tedious,
# fixing all the analyzer warnings will take quite some time. Having it on as you write new code
# is not so bad though, the IDE will handle it most of the time.
#
# Most people probably want this lint rule OFF, but for now we keep it on in our projects.
# We might reconsider this choice later. For example, this issue has requested
# a new softer related lint rule that could be used only for declarations:
# https://github.com/dart-lang/linter/issues/1620
# If such a lint rule materializes, we might switch to using it instead and turn off this lint.
#
# Using always_specify_type ON lint like Flutter repo does, makes it easier to reason about
# unfamiliar codebases, especially when you read it on GitHub where the IDE cannot be used to
# look into what type an object is.
#
# We felt the above long explanation was warranted as a reminder. Keeping the rule listed here
# and the setting below, in order to easily turn it OFF permanently some day, or in some
# projects.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike enabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# always_specify_types: false
# ALWAYS use package imports for files in lib/.
#
# https://dart-lang.github.io/linter/lints/always_use_package_imports.html
#
# This rule conflicts with `prefer_relative_imports` so we turn it OFF.
# We are still conflicted about which version to use, keeping it this way for now. Support
# for relative imports has improved in both IDEs. Adding imports still often get imported as
# package imports, and then you have to edit them manually. The IDEs can help with fixing them.
# The relative paths can be a bit messy to keep track off, package imports are actually
# a bit easier from that point of view.
# Flutter repo now also prefers relative imports over package imports, so that is
# another reason to use that.
#
# Use what you prefer, but you have to be consistent though, since mixing and matching can
# cause issues as the same file imported with the different options are considered to be
# different libs and code, even if it is the same file. This may impact the functionality
# of e.g. singletons, service locators and increase code size.
#
# When you refactor and move folders with a lot of code in them, that other code depends
# on for imports via relative imports, then they get messed up by Flutter IDEs
# VS-Code and AS/IntelliJ. Both main Flutter IDEs may fail to correctly refactor moved folders
# and imports that depend on files in the moved folders.
#
# Other known linters use:
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
always_use_package_imports: false
# AVOID annotating with dynamic when not required.
#
# https://dart-lang.github.io/linter/lints/avoid_annotating_with_dynamic.html
#
# Violates Effective Dart "PREFER annotating with dynamic instead of letting inference fail", it
# also conflicts with strong mode disabling `implicit-dynamic`. Turning it OFF.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_annotating_with_dynamic: false
# AVOID catches without on clauses.
#
# https://dart-lang.github.io/linter/lints/avoid_catches_without_on_clauses.html
#
# Using catch clauses without on clauses makes your code prone to encountering unexpected
# errors that won't be thrown (and thus will go unnoticed). However, there are situations
# where we voluntarily want to catch everything, especially as a library.
# See https://github.com/dart-lang/linter/issues/3023
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_catches_without_on_clauses: false
# AVOID defining a class that contains only static members.
#
# https://dart-lang.github.io/linter/lints/avoid_classes_with_only_static_members.html
#
# Creating classes with the sole purpose of providing utility, or otherwise static methods, is
# discouraged in effective Dart. Dart allows functions to exist outside of classes for this
# very reason. Effective Dart says avoid classes with only static members:
# https://dart.dev/guides/language/effective-dart/design#avoid-defining-a-class-that-contains-only-static-members
# However, the Flutter style guide says use them when it makes sense:
# https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#begin-global-constant-names-with-prefix-k
# Colors is an example of such a class, but they still enable this rule in the repo though, go figure.
#
# Like Pedantic, we like util and static classes too, so we use them.
# We tried the Effective Dart style and used kConstants in different const files. This
# is more cumbersome to use than static classes. The import is simpler with static classes and
# the code looks cleaner. If you use a lot of constant files, importing them is more tedious,
# and you cannot enforce a given 'as' name to have a consistent name space prefix. A static
# class gives you that automatically, thus providing context for the constants and static functions.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_classes_with_only_static_members: false
# AVOID declaring parameters as final.
#
# https://dart-lang.github.io/linter/lints/avoid_final_parameters.html
#
# Declaring parameters as final can lead to unnecessarily verbose code,
# especially when using the "parameter_assignments" rule.
#
# This rule is turned off, so we can define final parameters when it makes
# sense to do so without triggering a lint rule.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_final_parameters: false
# AVOID positional boolean parameters.
#
# https://dart-lang.github.io/linter/lints/avoid_positional_boolean_parameters.html
#
# Positional boolean parameters are considered a bad practice because they are very ambiguous.
# Using named boolean parameters is much more readable because it inherently describes
# what the boolean value represents.
# In principle, we agree with the argument against positional booleans. However, positional booleans
# are OK when they are the ONLY boolean parameter in a callback, and also very handy when used in a
# model setter from the callback directly.
#
# Flutter API contains many callbacks with the signature: {void Function(bool) onChanged} often
# for UI toggle switches. To keep things tidy and clean with a model setter for such a callback,
# a setter method with a positional boolean is needed, a typical pattern is:
# Switch.adaptive(
# value: model.hideTooltips,
# onChanged: model.setHideTooltips,
# ),
#
# We are turning OFF this AVOID rule. Willing to reconsider if I get convinced there are better ways,
# and it does not get in the way of single none named bool callbacks.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_positional_boolean_parameters: false
# AVOID print calls in production code.
#
# https://dart-lang.github.io/linter/lints/avoid_print.html
#
# Our default is to have this rule enabled.
#
# In example apps you may want to print to the console. You may want to do so during development
# too. We keep the rule here, to handily disable/enable as and when needed. This lint rule is
# a good way to find print statements that you may have used during development in code that
# should not have them in production, so at least before committing the code in such
# projects, make sure to keep this rule enabled by commenting it out here.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints enabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# RELEASE: enabled : By commenting it out. (default)
# DEVELOPMENT: disabled : Uncomment below if the warnings bother you during dev or making a console app.
#
# avoid_print: false
# AVOID redundant argument values.
#
# https://dart-lang.github.io/linter/lints/avoid_redundant_argument_values.html
#
# Using redundant (default) argument values can be useful for in-code documentation
# purposes and also handy as a template when trying different settings in Flutter. It is often
# quicker when dealing with not well-known APIs to see parameter values in the call/constructor,
# instead of using the IDE to peek into its default to figure out what the defaults are.
# Occasionally, leaving a few redundant default valued parameters in the code is not that bad
# when you are developing something new. For public packages, you probably want to keep this
# rule enabled. I like to sometimes be explicit and specify values that are the same as
# default one, mostly to make an unfamiliar API more readable on GitHub.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# PACKAGE: enabled : By commenting it out below, often a good idea in packages.
# APPLICATION: disabled : With false value.
avoid_redundant_argument_values: false
# AVOID annotating types for function expression parameters.
#
# https://dart-lang.github.io/linter/lints/avoid_catches_without_on_clauses.html
#
# Annotating types for function expression parameters is usually unnecessary because the
# parameter types can almost always be inferred from the context, thus making the practice redundant.
# However, since we are using `always_specify_types`, we should not have this one ON either
# as it conflicts with it. Even if you do not do that, we still recommend keeping this rule OFF.
# While always specifying the type on callbacks is certainly a bit tedious and not necessary,
# it can sometimes improve readability, so let's not force them to not be allowed.
# Thus, even if you don't use `always_specify_types`, it is possible to sometimes specify
# them on closures when it improves the readability of unfamiliar closures.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
avoid_types_on_closure_parameters: false
# DO Use the cascading style when successively invoking methods on the same reference.
#
# https://dart-lang.github.io/linter/lints/cascade_invocations.html
#
# We disable this rule, just a personal preference, using them is fine though,
# but let's not enforce it.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
cascade_invocations: false
# DO invoke close on instances of dart.core.Sink.
#
# https://dart-lang.github.io/linter/lints/close_sinks.html
#
# Disabling it, may generate false positives. https://github.com/dart-lang/linter/issues/1381.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#close_sinks: false
# DO reference all public properties in debug method implementations.
#
# https://dart-lang.github.io/linter/lints/diagnostic_describe_all_properties.html
#
# Consider using this lint rule if you are making a public Flutter package, for private ones and private apps
# we recommend keeping it off as you probably won't be making diagnostic properties for all your
# classes, unless you are using a data class lib that does it for you via code generation.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# PACKAGE: enabled : By commenting it out.
# APPLICATION: disabled : With false value. (Default, assume we are making an app most of the time.)
diagnostic_describe_all_properties: false
# DO Use Flutter TO-DO format.
#
# https://dart-lang.github.io/linter/lints/flutter_style_todos.html
#
# Use Flutter-style todos with GitHub username. Useful if you are coding in a
# larger team, if not, you may also consider turning off the rule by removing
# its comment below.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike enabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#flutter_style_todos: false
# AVOID lines longer than 80 characters
#
# https://dart-lang.github.io/linter/lints/lines_longer_than_80_chars.html
#
# Using this rule will sometimes force a line of 81 characters to be split in two.
# As long as we try to respect the 80-character limit, going slightly above is fine.
#
# For packages, keep this rule enabled though, because the pub.dev dart format check will
# penalize package points if it does not adhere to strict Dart format rules, which
# requires max 80 char lines. This rule will then help you find cases where you go over
# and fix them manually when possible. Ironically, Flutter repo violates this rule, but
# if you do it in a package for pub.dev you get a score deduction. We often disable this rule
# if this is not a package, so we keep it listed here as a handy toggle.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# PACKAGE: enabled : By commenting it out. (Default, even if it is not a package, we start with this.)
# APPLICATION: disabled : With false value. (When/if short lines become problematic. We sometimes like 100 chars.)
# lines_longer_than_80_chars: false
# DO define default behavior outside switch statements.
#
# https://dart-lang.github.io/linter/lints/no_default_cases.html
#
# An experimental lint rule maturity wise. I enabled it, it seems to work well.
# Remove the comment below if it is causing issues.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike enabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#no_default_cases: false
# CONSIDER omitting type annotations for local variables.
#
# https://dart-lang.github.io/linter/lints/omit_local_variable_types.html
#
# Conflicts with 'always_specify_types' that is used, so then we can't have this rule either,
# besides we like being verbose and specific. Why and when would omitting the type for local
# variables be a good thing anyway, be specific, is our take on this.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic enabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
omit_local_variable_types: false
# PREFER asserts with a message string.
#
# https://dart-lang.github.io/linter/lints/prefer_asserts_with_message.html
#
# When assertions fail, it's not always simple to understand why. Adding a message to the
# assert function helps the developer to understand why the AssertionError occurs.
#
# While this is true, Dart does nowadays create very clear messages from assert-terms by default.
# Flutter SDK does not use this rule or style. When you use code from it for customized
# widgets, you will end up having to write your own messages for the code snippet.
#
# Rationale for not using this in Flutter SDK:
# "Assertions blocks don't require a message because they throw simple to understand errors"
#
# We agree, so we do not mind turning OFF this rule when it becomes tedious, but we start
# with it ON. With NNBD, you also usually need fewer asserts than you did before in Dart code,
# since NNBD made almost all "not null" assertions unnecessary.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# PACKAGE: enabled : By commenting it out. (default)
# APPLICATION: disabled : With false value. (If it gets tedious in an app, we may turn it off)
# prefer_asserts_with_message: false
# PREFER to define constructors, instead of static methods to create instances.
#
# https://dart-lang.github.io/linter/lints/prefer_constructors_over_static_methods.html
#
# Dart has named constructors. Static methods in other languages (java) are a workaround to
# not having named constructors.
#
# We don't mind this lint rule, it is OK, BUT we noticed that
# if you want/need to create instances of classes via static helpers in another class, that
# this lint rules complains about it. We are OK with preferring a named constructor over a
# static method to create an instance from within the same class. However, this lint rule
# complained about the above usage too, where we think it makes sense to use a static method.
# This rule currently complains about use cases that in some scenarios are impossible to comply
# with. Maybe this is another issue with this lint rule. We should investigate it further and
# report it if it is an issue. For now, we disable this rule.
# A past now resolved issue with this lint rule was: https://github.com/dart-lang/linter/issues/2149
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
prefer_constructors_over_static_methods: false
# DO use double quotes where they wouldn't require additional escapes.
#
# https://dart-lang.github.io/linter/lints/prefer_double_quotes.html
#
# This rule is mostly about what style you want to use and enforce, if any.
# It of course conflicts with rule:
# `prefer_single_quotes` : "DO use single quotes where they wouldn't require additional escapes."
# https://dart-lang.github.io/linter/lints/prefer_single_quotes.html
#
# For us single quotes are easier to type. On our ISO keyboards it is next to Enter key, and
# we don't need the Shift plus the far to reach nr 2 key on R1 to type it. Also, we don't think
# they compromise on readability.
# Then again, if you don't care and don't mind mixing and matching, then ALSO
# turning OFF `prefer_single_quotes` works fine too, and then you can use both options.
#
# We thought it was cleaner to stick to one style. Single quotes are easier to type for us,
# thus we turn OFF this `prefer_double_quotes` rule. There is another lint rule that recommends
# you to use double quotes when you otherwise would need to escape the single quote char, it works
# well when you use the prefer_single_quotes rule as well.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
prefer_double_quotes: false
# CONSIDER using => for short members whose body is a single return statement.
#
# https://dart-lang.github.io/linter/lints/prefer_expression_function_bodies.html
#
# Certainly a good idea in many cases, but not always. For example, not always 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, and it might not even fit on a single line.
# https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#consider-using--for-short-functions-and-methods
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
prefer_expression_function_bodies: false
# DO prefer declaring parameters as final if they are not reassigned in the function body.
#
# https://dart-lang.github.io/linter/lints/prefer_final_parameters.html
#
# Declaring parameters as final when possible is a good practice because it helps
# avoid accidental reassignments.
#
# Certainly a good idea in many cases. There seems to be one "small" false positive issue with it.
# Lint is triggered by final constructor properties, e.g. in
# `final int i;` the parameter `this.i` is not also final, which is not really needed
# since the property is final. However, this triggers the rule unnecessarily. We had to
# turn OFF this rule due to it.
#
# We turned OFF the rule. In a test project, after we cleaned up all that could be after Flutter 2.5 upgrade.
# There were still 150 positives from the rule, from above issue. So after having it on and doing cleanup
# where it could be used, we turned off the rule for now. Pity, it is a useful and nice rule otherwise.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
prefer_final_parameters: false
# DO use int literals rather than the corresponding double literal.
#
# https://dart-lang.github.io/linter/lints/prefer_int_literals.html
#
# This rule goes against the preferred style of being explicit with
# declarations and hides when a number is double, since we cannot declare it
# as 0.0 or 1.0 when it is double, it has to be 0 or 1, making it look
# like an integer, even if it is not. Sometimes doing that is OK, but let's
# not enforce it.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
prefer_int_literals: false
# DO document all public members.
#
# https://dart-lang.github.io/linter/lints/public_member_api_docs.html
#
# All non-overriding public members should be documented with /// doc-style comments.
# Not necessary for an app or the examples in a pub.dev package. I always enable this for
# public packages.
#
# NOTE: There is also the lint rule "package_api_docs", that is enabled as well via all being enabled.
# https://dart-lang.github.io/linter/lints/package_api_docs.html
# "DO provide doc comments for all public APIs.", is what it is supposed to do, but only for
# packages. However, if we turn OFF the rule "public_member_api_docs", then the
# "package_api_docs" offers no warnings on missing API doc comments alone. So our conclusion
# for now is that this rule has to be used instead to ensure we find all APIs that should
# have documentation comments in a package as well.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
# PACKAGE: enabled : By commenting it out. (My default, I start with this)
# APPLICATION: disabled : With false value. (But usually uncomment the false value if it is an app)
# public_member_api_docs: false
# DO use trailing commas for all function calls and declarations unless the function call or
# definition, from the start of the function name up to the closing parenthesis,
# fits in a single line.
#
# https://dart-lang.github.io/linter/lints/require_trailing_commas.html
#
# This rule forces commas even in places where it just adds extra lines, that
# adds little value. There is also not a bulk dart fix for it:
# https://github.com/dart-lang/sdk/issues/47441
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint enabled : https://pub.dev/packages/lint
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
require_trailing_commas: false
# DO sort constructor declarations before other members.
#
# We do like this lint rule, but we want to have the default constructor first, followed
# by its properties, after this, other named constructors and factories. This rule gets
# in the way of that and forces you to put (often final) constructor properties after all
# the named constructors and factories, making them tedious to find and disconnected from
# where we want to see, read and handily edit them. This is especially the case if there are
# many constructors and factories, and they have a lot of parameters. For now, we disable
# this rule and order things as described above, which apart from the default constructor
# properties coming right after the constructor, is the only part where we in practice
# deviate from this rule, so other yes, we do put constructors first as well anyway.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# Lint disabled : https://pub.dev/packages/lint
# Discussion https://github.com/passsy/dart-lint/issues/1
# VG Analysis enabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
sort_constructors_first: false
# DON'T use final for local variables.
#
# https://dart-lang.github.io/linter/lints/unnecessary_final.html
#
# Incompatible with `prefer_final_locals` that we want because having immutable local variables when
# applicable makes larger functions more predictable and easier to reason about, so we
# use `prefer_final_locals` instead.
#
# Other known linters use:
#
# Core disabled : https://pub.dev/packages/lints
# Recommended disabled : https://pub.dev/packages/lints
# Flutter Lints disabled : https://pub.dev/packages/flutter_lints
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
# VG Analysis disabled : https://pub.dev/packages/very_good_analysis
# RydMike disabled : https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
unnecessary_final: false