|
599 | 599 | "state": "stable", |
600 | 600 | "incompatible": [], |
601 | 601 | "sets": [], |
602 | | - "fixStatus": "hasFix", |
| 602 | + "fixStatus": "noFix", |
603 | 603 | "details": "**AVOID** using a parameter name that is the same as an existing type.\n\n**BAD:**\n```dart\nm(f(int));\n```\n\n**GOOD:**\n```dart\nm(f(int v));\n```", |
604 | 604 | "sinceDartSdk": "2.0" |
605 | 605 | }, |
|
1954 | 1954 | "state": "stable", |
1955 | 1955 | "incompatible": [], |
1956 | 1956 | "sets": [], |
1957 | | - "fixStatus": "needsFix", |
| 1957 | + "fixStatus": "hasFix", |
1958 | 1958 | "details": "**DO** use `forEach` if you are only going to apply a function or a method\nto all the elements of an iterable.\n\nUsing `forEach` when you are only going to apply a function or method to all\nelements of an iterable is a good practice because it makes your code more\nterse.\n\n**BAD:**\n```dart\nfor (final key in map.keys.toList()) {\n map.remove(key);\n}\n```\n\n**GOOD:**\n```dart\nmap.keys.toList().forEach(map.remove);\n```\n\n**NOTE:** Replacing a for each statement with a forEach call may change the\nbehavior in the case where there are side-effects on the iterable itself.\n```dart\nfor (final v in myList) {\n foo().f(v); // This code invokes foo() many times.\n}\n\nmyList.forEach(foo().f); // But this one invokes foo() just once.\n```", |
1959 | 1959 | "sinceDartSdk": "2.0" |
1960 | 1960 | }, |
|
2447 | 2447 | "details": "NOTE: This rule is removed in Dart 3.0.0; it is no longer functional.\n\n**DO** place the `super` call last in a constructor initialization list.\n\nField initializers are evaluated in the order that they appear in the\nconstructor initialization list. If you place a `super()` call in the middle of\nan initializer list, the superclass's initializers will be evaluated right then\nbefore evaluating the rest of the subclass's initializers.\n\nWhat it doesn't mean is that the superclass's constructor body will be executed\nthen. That always happens after all initializers are run regardless of where\n`super` appears. It's vanishingly rare that the order of initializers matters,\nso the placement of `super` in the list almost never matters either.\n\nGetting in the habit of placing it last improves consistency, visually\nreinforces when the superclass's constructor body is run, and may help\nperformance.\n\n**BAD:**\n```dart\nView(Style style, List children)\n : super(style),\n _children = children {\n```\n\n**GOOD:**\n```dart\nView(Style style, List children)\n : _children = children,\n super(style) {\n```", |
2448 | 2448 | "sinceDartSdk": "2.0" |
2449 | 2449 | }, |
| 2450 | + { |
| 2451 | + "name": "switch_on_type", |
| 2452 | + "description": "Avoid switch statements on a 'Type'.", |
| 2453 | + "categories": [ |
| 2454 | + "unintentional", |
| 2455 | + "style", |
| 2456 | + "languageFeatureUsage", |
| 2457 | + "errorProne" |
| 2458 | + ], |
| 2459 | + "state": "stable", |
| 2460 | + "incompatible": [], |
| 2461 | + "sets": [], |
| 2462 | + "fixStatus": "noFix", |
| 2463 | + "details": "**AVOID** using switch on `Type`.\n\nSwitching on `Type` is not type-safe and can lead to bugs if the\nclass hierarchy changes. Prefer to use pattern matching on the variable\ninstead.\n\n**BAD:**\n```dart\nvoid f(Object o) {\n switch (o.runtimeType) {\n case int:\n print('int');\n case String:\n print('String');\n }\n}\n```\n\n**GOOD:**\n```dart\nvoid f(Object o) {\n switch(o) {\n case int():\n print('int');\n case String _:\n print('String');\n default:\n print('other');\n }\n}\n```", |
| 2464 | + "sinceDartSdk": "3.9" |
| 2465 | + }, |
2450 | 2466 | { |
2451 | 2467 | "name": "test_types_in_equals", |
2452 | 2468 | "description": "Test type of argument in `operator ==(Object other)`.", |
|
2928 | 2944 | "details": "Unnecessary `toList()` in spreads.\n\n**BAD:**\n```dart\nchildren: <Widget>[\n ...['foo', 'bar', 'baz'].map((String s) => Text(s)).toList(),\n]\n```\n\n**GOOD:**\n```dart\nchildren: <Widget>[\n ...['foo', 'bar', 'baz'].map((String s) => Text(s)),\n]\n```", |
2929 | 2945 | "sinceDartSdk": "2.18" |
2930 | 2946 | }, |
| 2947 | + { |
| 2948 | + "name": "unnecessary_unawaited", |
| 2949 | + "description": "Unnecessary use of 'unawaited'.", |
| 2950 | + "categories": [ |
| 2951 | + "brevity", |
| 2952 | + "unintentional", |
| 2953 | + "unusedCode" |
| 2954 | + ], |
| 2955 | + "state": "stable", |
| 2956 | + "incompatible": [], |
| 2957 | + "sets": [], |
| 2958 | + "fixStatus": "hasFix", |
| 2959 | + "details": "A call to a function, method, or operator, or a reference to a field,\ngetter, or top-level variable which is annotated with `@awaitNotRequired`\ndoes not need to be wrapped in a call to `unawaited()`.\n\n**BAD:**\n```dart\n@awaitNotRequired\nFuture<LogMessage> log(String message) { ... }\n\nvoid f() {\n unawaited(log('Message.'));\n}\n```\n\n**GOOD:**\n```dart\n@awaitNotRequired\nFuture<LogMessage> log(String message) { ... }\n\nvoid f() {\n log('Message.');\n}\n```", |
| 2960 | + "sinceDartSdk": "3.9" |
| 2961 | + }, |
2931 | 2962 | { |
2932 | 2963 | "name": "unnecessary_underscores", |
2933 | 2964 | "description": "Unnecessary underscores can be removed.", |
|
3086 | 3117 | "state": "stable", |
3087 | 3118 | "incompatible": [], |
3088 | 3119 | "sets": [], |
3089 | | - "fixStatus": "needsFix", |
| 3120 | + "fixStatus": "hasFix", |
3090 | 3121 | "details": "From [Effective Dart](https://dart.dev/effective-dart/usage#prefer-using--to-convert-null-to-a-boolean-value):\n\nUse `??` operators to convert `null`s to `bool`s.\n\n**BAD:**\n```dart\nif (nullableBool == true) {\n}\nif (nullableBool != false) {\n}\n```\n\n**GOOD:**\n```dart\nif (nullableBool ?? false) {\n}\nif (nullableBool ?? true) {\n}\n```", |
3091 | 3122 | "sinceDartSdk": "2.13" |
3092 | 3123 | }, |
|
0 commit comments