specify_nonobvious_property_types

Specify non-obvious type annotations for top-level and static variables.

This rule is currently experimental and not yet available in a stable SDK.

This rule has a quick fix available.

Do type annotate initialized top-level or static variables when the type is non-obvious.

Type annotations on top-level or static variables can serve as a request for type inference, documenting the expected outcome of the type inference step, and declaratively allowing the compiler and analyzer to solve the possibly complex task of finding type arguments and annotations in the initializing expression that yield the desired result.

Type annotations on top-level or static variables can also inform readers about the type of the initializing expression, which will allow them to proceed reading the locations in code where this variable is used with known good information about the type of the given variable (which may not be immediately evident by looking at the initializing expression).

An expression is considered to have a non-obvious type when it does not have an obvious type.

An expression e has an obvious type in the following cases:

• e is a non-collection literal. For instance, 1, true, 'Hello, $name!'.
• e is a collection literal with actual type arguments. For instance, <int, bool>{}.
• e is a list literal or a set literal where at least one element has an obvious type, and all elements have the same type. For instance, [1, 2] and { [true, false], [] }, but not [1, 1.5].
• e is a map literal where all key-value pair have a key with an obvious type and a value with an obvious type, and all keys have the same type, and all values have the same type. For instance, { #a:[] }, but not {1: 1, 2: true}.
• e is an instance creation expression whose class part is not raw. For instance C(14) if C is a non-generic class, or C(14) if C accepts one type argument, but not C(14) if C accepts one or more type arguments.
• e is a cascade whose target has an obvious type. For instance, 1..isEven..isEven has an obvious type because 1 has an obvious type.
• e is a type cast. For instance, myComplexpression as int.

BAD:

final myTopLevelVariable =
    genericFunctionWrittenByOtherFolks(with, args);

class A {
  static var myStaticVariable =
      myTopLevelVariable.update('foo', null);
}

GOOD:

final Map<String, Widget?> myTopLevelVariable =
    genericFunctionWrittenByOtherFolks(with, args);

class A {
  static Map<String, Widget?> myStaticVariable =
      myTopLevelVariable.update('foo', null);
}

This rule is experimental. It is being evaluated, and it may be changed or removed. Feedback on its behavior is welcome! The main issue is here: https://github.com/dart-lang/linter/issues/5101.

To enable the specify_nonobvious_property_types rule, add specify_nonobvious_property_types under linter > rules in your analysis_options.yaml file:

linter:
  rules:
    - specify_nonobvious_property_types

Unless stated otherwise, the documentation on this site reflects Dart 3.5.4. Page last updated on 2024-07-03. View source or report an issue.