specify_nonobvious_property_types

トップレベル変数と静的変数の、わかりにくい型アノテーションを指定します。

型がわかりにくい初期化済みのトップレベル変数または静的変数には、型アノテーションを付けます。

トップレベル変数または静的変数への型アノテーションは、型推論への要求として機能し、型推論ステップの期待される結果を文書化し、コンパイラとアナライザが、望ましい結果をもたらす初期化式内の型引数とアノテーションを見つけるという、おそらく複雑なタスクを宣言的に解決することを可能にします。

トップレベル変数または静的変数への型アノテーションは、初期化式の型を読者に伝えることもできます。これにより、読者は、その変数の型に関する既知の正しい情報を持って、この変数が使用されているコードの場所を読み進めることができます（これは、初期化式を見ただけではすぐに明らかにならない場合があります）。

式は、わかりにくい型を持たない場合、わかりにくい型を持つと見なされます。

式 e は、以下のケースでわかりやすい型を持ちます。

• e はコレクションリテラルではないリテラルです。例: 1、true、'Hello, $name!'。
• e は、実際の型引数を持つコレクションリテラルです。例: <int, bool>{}。
• e は、少なくとも1つの要素がわかりやすい型を持ち、すべての要素が同じ型を持つリストリテラルまたはセットリテラルです。例: [1, 2] および { [true, false], [] } ですが、[1, 1.5] は該当しません。
• e は、すべてのキーと値のペアがわかりやすい型のキーとわかりやすい値の値を持ち、すべてのキーが同じ型で、すべての値が同じ型であるマップリテラルです。例: { #a[] } ですが、{1: 1, 2: true} は該当しません。
• e は、クラス部分が生のインスタンスではないインスタンス作成式です。例: C が非ジェネリッククラスの場合 C(14)、または C が1つの型引数を受け付ける場合 C(14) ですが、C が1つ以上の型引数を受け付ける場合 C(14) は該当しません。
• e は、ターゲットがわかりやすい型を持つカスケードです。例: 1..isEven..isEven は、1がわかりやすい型を持つため、わかりやすい型を持ちます。
• e は型キャストです。例: myComplexExpression as int。

悪い例

final myTopLevelVariable =
    genericFunctionWrittenByOtherFolks(with, args);

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

良い例

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

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

このルールは実験的です。現在評価中であり、変更または削除される可能性があります。その動作に関するフィードバックを歓迎します！主な問題はこちらにあります: https://github.com/dart-lang/sdk/issues/59550。

specify_nonobvious_property_types ルールを有効にするには、analysis_options.yaml ファイルの linter > rules の下に specify_nonobvious_property_types を追加してください。

linter:
  rules:
    - specify_nonobvious_property_types

代わりに linter ルールを構成するために YAML マップ構文を使用している場合は、linter > rules の下に specify_nonobvious_property_types: true を追加してください。

linter:
  rules:
    specify_nonobvious_property_types: true