型推論が役立つのはなぜですか？

私はコードを書くよりも頻繁にコードを読みますが、産業用ソフトウェアに取り組んでいるプログラマーのほとんどがこれを行うと仮定しています。型推論の利点は、冗長性が少なく、コードが少ないことです。しかし一方で、コードをより頻繁に読む場合は、おそらく読み取り可能なコードが必要になります。

コンパイラーは型を推測します。これには古いアルゴリズムがあります。しかし、本当の質問は、プログラマーがコードを読むときに変数のタイプを推測したいのはなぜですか？誰がタイプを読むだけで、どのタイプがあるかを考えるよりも速くないですか？

編集：結論として、なぜそれが役立つのかを理解しています。しかし、言語機能のカテゴリでは、演算子がオーバーロードしているバケツの中にあります-場合によっては便利ですが、乱用された場合は読みやすさに影響します。

Javaを見てみましょう。Javaは、推論された型を持つ変数を持つことはできません。これは、たとえタイプが何であるかが人間の読者に完全に明らかであるとしても、頻繁にタイプを説明する必要があることを意味します。

int x = 42;  // yes I see it's an int, because it's a bloody integer literal!

// Why the hell do I have to spell the name twice?
SomeObjectFactory<OtherObject> obj = new SomeObjectFactory<>();

そして時々、タイプ全体を綴るのは単純に迷惑なだけです。

// this code walks through all entries in an "(int, int) -> SomeObject" table
// represented as two nested maps
// Why are there more types than actual code?
for (Map.Entry<Integer, Map<Integer, SomeObject<SomeObject, T>>> row : table.entrySet()) {
    Integer rowKey = entry.getKey();
    Map<Integer, SomeObject<SomeObject, T>> rowValue = entry.getValue();
    for (Map.Entry<Integer, SomeObject<SomeObject, T>> col : rowValue.entrySet()) {
        Integer colKey = col.getKey();
        SomeObject<SomeObject, T> colValue = col.getValue();
        doSomethingWith<SomeObject<SomeObject, T>>(rowKey, colKey, colValue);
    }
}

この冗長な静的型付けは、プログラマーである私を邪魔します。ほとんどのタイプアノテーションは、既に知られている内容の繰り返しのある、行を埋める、コンテンツのない変更です。しかし、バグを発見するのに本当に役立つので、静的型付けが好きです。したがって、動的型付けを使用することは必ずしも良い答えではありません。型推論は両方の長所です。無関係な型は省略できますが、プログラム（型）がチェックアウトされることを確認してください。

型推論はローカル変数には本当に便利ですが、明確に文書化する必要があるパブリックAPIには使用しないでください。また、コードで何が起こっているのかを理解するために、型が本当に重要な場合もあります。そのような場合、型推論だけに依存するのは愚かなことです。

型推論をサポートする多くの言語があります。例えば：

• C ++。autoキーワードトリガーは推論を入力します。それがなければ、ラムダのタイプやコンテナ内のエントリのタイプを書くのは地獄だろう。

• C＃。を使用して変数を宣言できますvar。これにより、限定された形式の型推論がトリガーされます。型推論を必要とするほとんどの場合を引き続き管理します。特定の場所では、型を完全に除外できます（ラムダなど）。

• Haskell、およびMLファミリーの任意の言語。ここで使用される型推論の特定のフレーバーは非常に強力ですが、多くの場合、関数の型注釈が表示されることが多く、2つの理由があります。1つ目はドキュメントで、2つ目は型推論が実際に期待する型を見つけたことを確認することです。矛盾がある場合は、何らかのバグがある可能性があります。

コードが書かれているよりもはるかに頻繁に読まれることは事実です。ただし、読み取りにも時間がかかり、2画面のコードは1画面のコードよりもナビゲートして読み取るのが難しいため、最適な有用な情報/読み取り努力の比率を詰めるために優先順位を付ける必要があります。これは、一般的なUXの原則です。一度に大量の情報があふれ、実際にインターフェイスの有効性が低下します。

そして、私の経験では、多くの場合、正確なタイプは重要ではありません。確かx + y * zにmonkey.eat(bananas.get(i))、式をネストすることもあります：、、factory.makeCar().drive()。これらにはそれぞれ、タイプが書き出されていない値に評価される部分式が含まれています。しかし、それらは完全に明確です。コンテキストから把握するのは十分に簡単であるため、このタイプを明記しないでかまいませんし、それを書き出すことは、良いことよりも害をもたらすでしょう（データフローの理解を混乱させ、貴重な画面と短期のメモリスペースを取ります）。

明日がないように式をネストしない理由の1つは、行が長くなり、値の流れが不明確になることです。一時変数の導入はこれに役立ち、順序を課し、部分的な結果に名前を付けます。ただし、これらの側面から恩恵を受けるものすべてが、そのタイプを綴ることから恩恵を受けるわけではありません。

user = db.get_poster(request.post['answer'])
name = db.get_display_name(user)

userエンティティオブジェクト、整数、文字列、または他の何かであるかどうかは重要ですか？ほとんどの目的では、ユーザーを表し、HTTPリクエストから取得し、名前の取得に使用して回答の右下隅に表示されることを知るだけで十分です。

そして、それが重要な場合、著者はタイプを自由に書き出すことができます。これは責任を持って使用しなければならない自由ですが、可読性を高めることができる他のすべて（変数名と関数名、フォーマット、APIデザイン、空白）にも同じことが言えます。そして実際、HaskellとML（すべてを余計な労力なしで推論できる）の慣習は、非ローカル関数関数のタイプ、および適切な場合にはローカル変数と関数のタイプを書き出すことです。すべてのタイプを推測できるのは初心者のみです。

型推論は非常に重要であり、あらゆる現代言語でサポートされるべきだと思います。私たちはすべてIDEで開発しており、推測されたタイプを知りたい場合に役立つことがありますvi。たとえば、Javaの冗長性とセレモニーコードを考えてください。

  Map<String,HashMap<String,String>> map = getMap();

しかし、あなたは私のIDEが私を助けてくれれば良いと言うことができます、それは有効なポイントかもしれません。ただし、一部の機能は、たとえばC＃匿名型などの型推論の助けなしには存在しません。

 var person = new {Name="John Smith", Age = 105};

Linqは、型推論の助けなしでは今ほど良くないでしょう。Select例えば

  var result = list.Select(c=> new {Name = c.Name.ToUpper(), Age = c.DOB - CurrentDate});

この匿名型は変数にきちんと推論されます。

私Scalaはあなたのポイントがここに当てはまると思うので、戻り型の型推論を嫌います。APIがより流useに使用できるように、関数が返すものが明確であるはずです

これに対する答えは本当に簡単だと思います。冗長な情報の読み書きを節約できます。特に、等号の両側に型があるオブジェクト指向言語では。

また、情報が冗長でない場合に、使用する必要があるかどうかを示します。

コードを見たとしましょう：

someBigLongGenericType variableName = someBigLongGenericType.someFactoryMethod();

場合someBigLongGenericTypeの戻り値の型から割り当て可能でsomeFactoryMethod、型が正確に一致しない場合はどのように可能性の高いコードを読んで誰かが通知になり、そしてどのように容易に予告食い違いをした誰かが、それは意図的だったかどうかを認識することができますか？

推論を許可することにより、言語はコードを読んでいる人に、変数の型が明示的に述べられているとき、その人がその理由を見つけようとすることを提案できます。これにより、コードを読んでいる人が自分の努力に集中できるようになります。対照的に、型が指定されている時間の大部分が推測されたものとまったく同じである場合、コードを読んでいる人は微妙に異なる時間に気付かない傾向があります。

すでに多くのすばらしい答えがあることがわかります。そのうちのいくつかは繰り返しますが、時々あなたは自分の言葉で物事を置きたいだけです。それは私が最も精通している言語なので、C ++のいくつかの例でコメントします。

必要なことは決して賢明ではありません。他の言語機能を実用的にするには、型推論が必要です。C ++では、発話できない型を持つことができます。

struct {
    double x, y;
} p0 = { 0.0, 0.0 };
// there is no name for the type of p0
auto p1 = p0;

C ++ 11は、やはり発言できないラムダを追加しました。

auto sq = [](int x) {
    return x * x;
};
// there is no name for the type of sq

型推論もテンプレートを支えています。

template <class x_t>
auto sq(x_t const& x)
{
    return x * x;
}
// x_t is not known until it is inferred from an expression
sq(2); // x_t is int
sq(2.0); // x_t is double

しかし、あなたの質問は、「プログラマーが、コードを読むときに変数の型を推測したいのはなぜでしょうか。誰が型を読むだけで、どの型があるかを考えるよりも速くないのですか？」

型推論は冗長性を取り除きます。コードの読み取りに関しては、コードに冗長な情報を含める方が高速で簡単な場合がありますが、冗長な情報は有用な情報を覆い隠す可能性があります。例えば：

std::vector<int> v;
std::vector<int>::iterator i = v.begin();

C ++プログラマーがiがイテレーターであることを識別するのに標準ライブラリーにあまり慣れていないi = v.begin()ため、明示的な型宣言の値は制限されます。その存在により、より重要な詳細（iベクトルの先頭を指すなど）があいまいになります。@amonによるすばらしい回答は、重要な詳細を覆い隠す冗長性のさらに良い例を提供します。対照的に、型推論を使用すると、重要な詳細がより顕著になります。

std::vector<int> v;
auto i = v.begin();

コードの読み取りは重要ですが、十分ではありませんが、ある時点で読み取りを停止し、新しいコードの書き込みを開始する必要があります。コードの冗長性により、コードの変更がより遅く、より難しくなります。たとえば、次のコードの断片があるとします。

std::vector<int> v;
std::vector<int>::iterator i = v.begin();

ベクトルの値型を変更してコードを二重に変更する必要がある場合：

std::vector<double> v;
std::vector<double>::iterator i = v.begin();

この場合、2つの場所でコードを変更する必要があります。元のコードが次の場合の型推論とは対照的です。

std::vector<int> v;
auto i = v.begin();

そして変更されたコード：

std::vector<double> v;
auto i = v.begin();

コードを1行変更するだけでよいことに注意してください。これを大規模なプログラムに外挿すると、型の推論は、エディターを使用した場合よりもはるかに迅速に変更を型に反映できます。

コードの冗長性により、バグが発生する可能性があります。コードが同等に保たれている2つの情報に依存しているときはいつでも、間違いの可能性があります。たとえば、このステートメントの2つのタイプの間に矛盾がありますが、これはおそらく意図されていません。

int pi = 3.14159;

冗長性は、意図を見分けるのを難しくします。型の推論は、明示的な型の指定よりも簡単であるため、読みやすく、理解しやすい場合があります。コードの断片を考えてみましょう：

int y = sq(x);

をsq(x)返す場合、がの戻り型であるか、を使用するステートメントに適しているため、であるintかyは明らかではありません。が返されないように他のコードを変更すると、その行だけではタイプの更新が必要かどうかがわかりません。同じコードですが、型推論を使用しているのと対照的です：intsq(x)ysq(x)inty

auto y = sq(x);

この場合、意図は明確でyあり、によって返されるのと同じ型でなければなりませんsq(x)。コードがの戻りsq(x)タイプをy変更すると、変更のタイプは自動的に一致します。

C ++では、上記の例が型推論を使用してより単純になる2番目の理由があります。型推論は暗黙的な型変換を導入できません。の戻り値の型がsq(x)でないint場合、コンパイラは暗黙的に暗黙の変換をに挿入しintます。の戻り型がsq(x)を定義する型複合型であるoperator int()場合、この非表示の関数呼び出しは任意に複雑になる可能性があります。