重複の可能性:
ベスト プラクティス: Option Infer
VB.NET の Option Strict と新しい Option Infer ディレクティブを組み合わせる最適な方法は何ですか?
VB6 から VB.NET に変換された古いソリューションを開発しています。
実際、ファイルのデフォルトのオプションは
Option Strict On
Option Explicit On
LINQ を使用したいのですが、LINQ も使いやすいことがわかりましたOption Infer On。
書くことが減り、読むことが減ります（つまり、より簡単になります）。
ただし、チームの (私の観点からは保守的な) 一部は、Option Infer Off を維持し、原因を明示的に説明せずに、まったく使用しないと主張しています。
あなたの意見では、Option Infer On を他の 2 つのオプション (Strict と Explicit、両方とも On) と共に使用することの「危険性」は何ですか?
on を使用して記述Option Inferされたコードは、同じ型を明示的に宣言して記述されたコードと、パフォーマンスまたはタイプ セーフに違いはありません。それを念頭に置いて、私が思いつくことができる議論は次のOption Inferとおりです。
型を指定する必要がある場合と、型を推測できる場合の不一致。
Dim f = Function(x) ...は、常に型を推論するとは限りません。この引数の強さは、既存のコードベースのスタイルの一貫性に正比例します。(たとえば、古いコードで作業する場合、新しいコンパイラが必要としない場合でも、その周りの残りのコードがアンダースコアを使用している場合でも、行を継続するためにアンダースコアを使用することがあります。)
コードを調べたときに型がすぐにわからない場合があります。
Dim temp = Foo() 'temp is type of Foo's return, which is...
回避策:必要に応じて、変数の型を宣言します。
これは潜在的な不便さほど「危険」ではありません。Intellisense が推論された型を伝えることができない環境で作業していない場合はなおさらです。
その場合、推論されたタイプは、実際に必要とするよりも具体的である可能性があります。
回避策:その場合は、必要な型を明確に宣言してください。
これが問題である場合、コンパイラはケースをキャッチするので、それ自体を「危険」とは呼びません。これがコンパイラがキャッチしない問題であると私が考えることができるのは、基本型と派生型のメソッドのオーバーロードが異なる場合、または派生型のメソッドをシャドーイングしている場合だけです。どちらの場合も、既存のコードの問題であり、Option Infer の問題ではないと私は主張します。
LINQ クエリで発生する匿名型を使用すると、メソッド間で渡すことができないため、通常よりもメソッドが大きくなる可能性があります。
回避策:これが発生した場合は名前付きの型を定義し、通常どおりメソッドを分割します。
長いメソッドが危険である限り、これはより危険です。通常の「長すぎる長さ」の議論が適用されます。
入力する必要のないすべての型名からコード ファイルの KB が少なくなるため、生産性が低下しているように見えます。（OK、これは冗談です。）
変数の型を推測する言語がますます増えています。C#、F#、およびおそらく .NET 以外の言語のホスト全体も検討してください。
でタイプ セーフを維持しoption infer onます。変数を指定するのが好きな人は、まだそうすることができます。しかし、LINQ を使用する際に暗号化された名前を使用することは、不可能に近い場合があり、コードの読み取りが確実に難しくなります。
私はかつて古い学校でした。しかし、推論が C# の世界に入ってからしばらくすると、それを認めるしかありませんでした。それは、コーディング速度、可読性、ひいては品質を向上させ、コードの保守を容易にします。これは、すべての変数の指定をやめるべきだという意味ではありません。多くの場合、infer がオンかオフかに関係なく、型を指定する方が適切です。繰り返しますが、読みやすさのために。
古い学校の人々に、なぜデフォルトでそれが必要なのかを説明し、必要に応じてタイプ名を入力できることを説明してください。
私の場合、すべてをオンにすることを好みます
ただし、Infer OFF は「OK」です。MORE と入力するだけです ;-)