関数パラメーターに注釈を付けないのはなぜですか？

この質問に答えられるようにするために、プログラマの心の中にある曖昧さのコストは、いくつかの余分なキーストロークよりもはるかに高価であると仮定しましょう。

それを考えると、なぜ私のチームメイトが機能パラメーターに注釈を付けないで逃げることができるのですか？はるかに複雑なコードの例として、次のコードをご覧ください。

let foo x y = x + y

これで、ツールチップを簡単に調べると、F＃がxとyがintを意味すると判断したことがわかります。それがあなたが意図したものであるなら、すべては順調です。しかし、それがあなたが意図したものかどうかはわかりません。2つの文字列を連結するためにこのコードを作成した場合はどうなりますか？または、ダブルスを追加するつもりだったと思う場合はどうなりますか？または、すべての単一の関数パラメーターの上にマウスを置いてそのタイプを決定する必要がない場合はどうなりますか？

これを例として見てみましょう。

let foo x y = "result: " + x + y

F＃では、おそらく文字列を連結することを想定しているため、xとyは文字列として定義されます。ただし、コードを保守している貧弱なシュマックとして、私はこれを見て、xとy（int）を一緒に追加し、UI目的のために文字列に結果を追加するつもりだったのではないかと思うかもしれません。

確かにこのような単純な例では手放すことができますが、明示的な型注釈のポリシーを強制しないのはなぜですか？

let foo (x:string) (y:string) = "result: " + x + y

明確であることにはどのような害がありますか？確かに、プログラマーは自分がやろうとしていることに対して間違ったタイプを選択する可能性がありますが、少なくとも私は彼らがそれを意図していたことを知っています。

これは深刻な質問です...私はまだF＃が初めてであり、会社の道を切り開いています。私が採用する標準は、今後のF＃コーディングの基礎となり、今後数年間、文化に浸透していくと確信している無限のコピーペーストに組み込まれます。

それで... F＃の型推論に特別な何かがあり、それを保持する価値のある機能にし、必要な場合にのみ注釈を付けますか？または、専門のF＃-ersは、自明ではないアプリケーションのパラメーターに注釈を付ける習慣をつけていますか？

私はF＃を使用しませんが、Haskellでは、言語に一般的な型推論がありますが、（少なくとも）トップレベルの定義、場合によってはローカルな定義に注釈を付けるのが良いと考えられています。これにはいくつかの理由があります。

• 読み取り
  関数の使用方法を知りたい場合は、タイプシグネチャを使用できると非常に便利です。自分で推測したり、ツールに頼ってあなたのためにしたりするのではなく、単に読むことができます。

• リファクタリング
  関数を変更する場合、明示的な署名を使用すると、変換によって元のコードの意図が維持されることが保証されます。型推論言語では、非常に多態的なコードは型チェックを行うが、意図したとおりには動作しないことがあります。型シグネチャは、インターフェイスで型情報を具体化する「バリア」です。

• パフォーマンス
  Haskellでは、関数の推論された型が（型クラスを介して）オーバーロードされる場合があり、これは実行時ディスパッチを意味する場合があります。数値型の場合、デフォルトの型は任意精度の整数です。これらの機能の完全な汎用性が必要ない場合は、必要な特定のタイプに関数を特化することでパフォーマンスを改善できます。

ローカル定義、let-bound変数、およびラムダへの仮パラメーターについては、通常、型シグネチャは追加する値よりもコードのコストが高くなることがわかります。そのため、コードレビューでは、最上位の定義の署名を主張し、他の場所で賢明な注釈を要求することをお勧めします。

ジョンはここでは繰り返さない合理的な答えを与えました。しかし、私はあなたのニーズを満たすかもしれないオプションを表示し、その過程でyes / no以外の異なるタイプの答えが表示されます。

最近、パーサーコンビネータを使用した解析を行っています。解析を知っていれば、通常、最初のフェーズでレクサーを使用し、2番目のフェーズでパーサーを使用していることがわかります。レクサーはテキストをトークンに変換し、パーサーはトークンをASTに変換します。F＃は関数型言語であり、コンビネーターは結合されるように設計されているため、パーサーコンビネーターは、レクサーとパーサーの両方で同じ関数を使用するように設計されていますが、パーサーコンビネーター関数のタイプを設定する場合にのみ使用できますlexまたはparseであり、両方ではありません。

例えば：

/// Parser that requires a specific item.

// a (tok : 'a) : ('a list -> 'a * 'a list)                     // generic
// a (tok : string) : (string list -> string * string list)     // string
// a (tok : token)  : (token list  -> token  * token list)      // token

または

/// Parses iterated left-associated binary operator.


// leftbin (prs : 'a -> 'b * 'c) (sep : 'c -> 'd * 'a) (cons : 'd -> 'b -> 'b -> 'b) (err : string) : ('a -> 'b * 'c)                                                                                    // generic
// leftbin (prs : string list -> string * string list) (sep : string list -> string * string list) (cons : string -> string -> string -> string) (err : string) : (string list -> string * string list)  // string
// leftbin (prs : token list  -> token  * token list)  (sep : token list  -> token  * token list)  (cons : token  -> token  -> token  -> token)  (err : string) : (token list  -> token  * token list)   // token

コードは著作権であるため、ここには含めませんが、Githubで入手できます。ここにコピーしないでください。

関数を機能させるには、汎用パラメーターを残しておく必要がありますが、関数の使用に応じて推測される型を示すコメントを含めます。これにより、汎用の関数を使用したまま、メンテナンス用の関数を簡単に理解できます。

バグの数は、プログラムの文字数に正比例します！

これは通常、コードの行に比例するバグの数として表されます。ただし、コードの量が同じで行数が少ないと、同じ量のバグが発生します。

そのため、明示的にするのは良いことですが、入力した余分なパラメーターはバグにつながる可能性があります。