@@ -340,7 +340,7 @@ previous guidelines state, either:
340
340
341
341
### PREFER naming a method ` to___() ` if it copies the object's state to a new object
342
342
343
- {% include 'linter-rule-mention.md', rules:'use_to_and_as_if_applicable' %}
343
+ {% render 'linter-rule-mention.md', rules:'use_to_and_as_if_applicable' %}
344
344
345
345
A * conversion* method is one that returns a new object containing a copy of
346
346
almost all of the state of the receiver but usually in some different form or
@@ -358,7 +358,7 @@ dateTime.toLocal();
358
358
359
359
### PREFER naming a method ` as___() ` if it returns a different representation backed by the original object
360
360
361
- {% include 'linter-rule-mention.md', rules:'use_to_and_as_if_applicable' %}
361
+ {% render 'linter-rule-mention.md', rules:'use_to_and_as_if_applicable' %}
362
362
363
363
Conversion methods are "snapshots". The resulting object has its own copy of the
364
364
original object's state. There are other conversion-like methods that return
@@ -520,7 +520,7 @@ you can in a procedural or functional language.
520
520
521
521
### AVOID defining a one-member abstract class when a simple function will do
522
522
523
- {% include 'linter-rule-mention.md', rules:'one_member_abstracts' %}
523
+ {% render 'linter-rule-mention.md', rules:'one_member_abstracts' %}
524
524
525
525
Unlike Java, Dart has first-class functions, closures, and a nice light syntax
526
526
for using them. If all you need is something like a callback, just use a
@@ -543,7 +543,7 @@ abstract class Predicate<E> {
543
543
544
544
### AVOID defining a class that contains only static members
545
545
546
- {% include 'linter-rule-mention.md', rules:'avoid_classes_with_only_static_members' %}
546
+ {% render 'linter-rule-mention.md', rules:'avoid_classes_with_only_static_members' %}
547
547
548
548
In Java and C#, every definition * must* be inside a class, so it's common to see
549
549
"classes" that exist only as a place to stuff static members. Other classes are
@@ -656,7 +656,7 @@ comment.
656
656
<a id =" avoid-mixing-in-a-class-that-isnt-intended-to-be-a-mixin " ></a >
657
657
### PREFER defining a pure ` mixin ` or pure ` class ` to a ` mixin class `
658
658
659
- {% include 'linter-rule-mention.md', rules:'prefer_mixin' %}
659
+ {% render 'linter-rule-mention.md', rules:'prefer_mixin' %}
660
660
661
661
Dart previously (language version [ 2.12] ( /guides/language/evolution#dart-2-12 )
662
662
to [ 2.19] ( /guides/language/evolution#dart-2-19 ) ) allowed any class that
@@ -708,7 +708,7 @@ A member belongs to an object and can be either methods or instance variables.
708
708
709
709
### PREFER making fields and top-level variables ` final `
710
710
711
- {% include 'linter-rule-mention.md', rules:'prefer_final_fields' %}
711
+ {% render 'linter-rule-mention.md', rules:'prefer_final_fields' %}
712
712
713
713
State that is not * mutable* —that does not change over time—is
714
714
easier for programmers to reason about. Classes and libraries that minimize the
@@ -821,7 +821,7 @@ dataSet.minimumValue;
821
821
822
822
### DO use setters for operations that conceptually change properties
823
823
824
- {% include 'linter-rule-mention.md', rules:'use_setters_to_change_properties' %}
824
+ {% render 'linter-rule-mention.md', rules:'use_setters_to_change_properties' %}
825
825
826
826
Deciding between a setter versus a method is similar to deciding between a
827
827
getter versus a method. In both cases, the operation should be "field-like".
@@ -847,7 +847,7 @@ button.visible = false;
847
847
848
848
### DON'T define a setter without a corresponding getter
849
849
850
- {% include 'linter-rule-mention.md', rules:'avoid_setters_without_getters' %}
850
+ {% render 'linter-rule-mention.md', rules:'avoid_setters_without_getters' %}
851
851
852
852
Users think of getters and setters as visible properties of an object. A
853
853
"dropbox" property that can be written to but not seen is confusing and
@@ -925,7 +925,7 @@ empty container, it might make sense to use a nullable type.
925
925
926
926
### AVOID returning ` this ` from methods just to enable a fluent interface
927
927
928
- {% include 'linter-rule-mention.md', rules:'avoid_returning_this' %}
928
+ {% render 'linter-rule-mention.md', rules:'avoid_returning_this' %}
929
929
930
930
Method cascades are a better solution for chaining method calls.
931
931
@@ -1049,7 +1049,7 @@ various cases, but the rough summary is:
1049
1049
1050
1050
### DO type annotate variables without initializers
1051
1051
1052
- {% include 'linter-rule-mention.md', rules:'prefer_typing_uninitialized_variables' %}
1052
+ {% render 'linter-rule-mention.md', rules:'prefer_typing_uninitialized_variables' %}
1053
1053
1054
1054
The type of a variable—top-level, local, static field, or instance
1055
1055
field—can often be inferred from its initializer. However, if there is no
@@ -1078,7 +1078,7 @@ if (node is Constructor) {
1078
1078
1079
1079
### DO type annotate fields and top-level variables if the type isn't obvious
1080
1080
1081
- {% include 'linter-rule-mention.md', rules:'type_annotate_public_apis' %}
1081
+ {% render 'linter-rule-mention.md', rules:'type_annotate_public_apis' %}
1082
1082
1083
1083
Type annotations are important documentation for how a library should be used.
1084
1084
They form boundaries between regions of a program to isolate the source of a
@@ -1130,7 +1130,7 @@ annotations on APIs help *users* of your code, types on private members help
1130
1130
1131
1131
### DON'T redundantly type annotate initialized local variables
1132
1132
1133
- {% include 'linter-rule-mention.md', rules:'omit_local_variable_types' %}
1133
+ {% render 'linter-rule-mention.md', rules:'omit_local_variable_types' %}
1134
1134
1135
1135
Local variables, especially in modern code where functions tend to be small,
1136
1136
have very little scope. Omitting the type focuses the reader's attention on the
@@ -1237,7 +1237,7 @@ different type annotation conventions, as described in the next two guidelines.
1237
1237
1238
1238
### DON'T annotate inferred parameter types on function expressions
1239
1239
1240
- {% include 'linter-rule-mention.md', rules:'avoid_types_on_closure_parameters' %}
1240
+ {% render 'linter-rule-mention.md', rules:'avoid_types_on_closure_parameters' %}
1241
1241
1242
1242
Anonymous functions are almost always immediately passed to a method taking a
1243
1243
callback of some type.
@@ -1268,7 +1268,7 @@ function's parameters. In those cases, you may need to annotate.
1268
1268
1269
1269
### DON'T type annotate initializing formals
1270
1270
1271
- {% include 'linter-rule-mention.md', rules:'type_init_formals' %}
1271
+ {% render 'linter-rule-mention.md', rules:'type_init_formals' %}
1272
1272
1273
1273
If a constructor parameter is using ` this. ` to initialize a field,
1274
1274
or ` super. ` to forward a super parameter,
@@ -1511,7 +1511,7 @@ void handleError([!void Function()!] operation, [!Function!] errorHandler) {
1511
1511
1512
1512
### DON'T specify a return type for a setter
1513
1513
1514
- {% include 'linter-rule-mention.md', rules:'avoid_return_types_on_setters' %}
1514
+ {% render 'linter-rule-mention.md', rules:'avoid_return_types_on_setters' %}
1515
1515
1516
1516
Setters always return ` void ` in Dart. Writing the word is pointless.
1517
1517
@@ -1528,7 +1528,7 @@ set foo(Foo value) { ... }
1528
1528
1529
1529
### DON'T use the legacy typedef syntax
1530
1530
1531
- {% include 'linter-rule-mention.md', rules:'prefer_generic_function_type_aliases' %}
1531
+ {% render 'linter-rule-mention.md', rules:'prefer_generic_function_type_aliases' %}
1532
1532
1533
1533
Dart has two notations for defining a named typedef for a function type. The
1534
1534
original syntax looks like:
@@ -1586,7 +1586,7 @@ it's deprecated.
1586
1586
1587
1587
### PREFER inline function types over typedefs
1588
1588
1589
- {% include 'linter-rule-mention.md', rules:'avoid_private_typedef_functions' %}
1589
+ {% render 'linter-rule-mention.md', rules:'avoid_private_typedef_functions' %}
1590
1590
1591
1591
In Dart, if you want to use a function type for a field, variable, or
1592
1592
generic type argument, you can define a typedef for the function type.
@@ -1623,7 +1623,7 @@ that clarity.
1623
1623
1624
1624
### PREFER using function type syntax for parameters
1625
1625
1626
- {% include 'linter-rule-mention.md', rules:'use_function_type_syntax_for_parameters' %}
1626
+ {% render 'linter-rule-mention.md', rules:'use_function_type_syntax_for_parameters' %}
1627
1627
1628
1628
Dart has a special syntax when defining a parameter whose type is a function.
1629
1629
Sort of like in C, you surround the parameter's name with the function's return
@@ -1758,7 +1758,7 @@ In Dart, optional parameters can be either positional or named, but not both.
1758
1758
1759
1759
### AVOID positional boolean parameters
1760
1760
1761
- {% include 'linter-rule-mention.md', rules:'avoid_positional_boolean_parameters' %}
1761
+ {% render 'linter-rule-mention.md', rules:'avoid_positional_boolean_parameters' %}
1762
1762
1763
1763
Unlike other types, booleans are usually used in literal form. Values like
1764
1764
numbers are usually wrapped in named constants, but we typically pass around
@@ -1872,7 +1872,7 @@ elements to follow.
1872
1872
1873
1873
### DO override ` hashCode ` if you override ` == `
1874
1874
1875
- {% include 'linter-rule-mention.md', rules:'hash_and_equals' %}
1875
+ {% render 'linter-rule-mention.md', rules:'hash_and_equals' %}
1876
1876
1877
1877
The default hash code implementation provides an * identity* hash—two
1878
1878
objects generally only have the same hash code if they are the exact same
@@ -1900,7 +1900,7 @@ you're trying to express.
1900
1900
1901
1901
### AVOID defining custom equality for mutable classes
1902
1902
1903
- {% include 'linter-rule-mention.md', rules:'avoid_equals_and_hash_code_on_mutable_classes' %}
1903
+ {% render 'linter-rule-mention.md', rules:'avoid_equals_and_hash_code_on_mutable_classes' %}
1904
1904
1905
1905
When you define ` == ` , you also have to define ` hashCode ` . Both of those should
1906
1906
take into account the object's fields. If those fields * change* then that
@@ -1912,7 +1912,7 @@ true.
1912
1912
1913
1913
### DON'T make the parameter to ` == ` nullable
1914
1914
1915
- {% include 'linter-rule-mention.md', rules:'avoid_null_checks_in_equality_operators' %}
1915
+ {% render 'linter-rule-mention.md', rules:'avoid_null_checks_in_equality_operators' %}
1916
1916
1917
1917
The language specifies that ` null ` is equal only to itself, and that the ` == `
1918
1918
method is called only if the right-hand side is not ` null ` .
0 commit comments