マイクロソフトは、C＃での 'var'の使用を推奨していませんか？（VS2017）

私は来たるVisual Studio 2017を見ています。

Boosted Productivityというタイトルのセクションの下に、すべてのvarの出現を明示的な型に置き換えるために使用されているVisual Studioのイメージがあります。

このコードには、Visual Studioが「修正が必要」と特定したいくつかの問題があるようです。

C＃でのvarの使用に関する理解を再確認したかったので、Eric Lippertによる2011年の暗黙的な型指定の使用と誤用に関する記事を読みました。

エリック言う：

必要な場合はvarを使用します。匿名型を使用している場合。

宣言のタイプが初期化子から明らかな場合、特にオブジェクト作成の場合は、varを使用します。これにより、冗長性がなくなります。

コードが変数のセマンティック「ビジネス目的」を強調し、そのストレージの「機械的」詳細を軽視する場合は、varの使用を検討してください。

コードを正しく理解して維持するために必要な場合は、明示的な型を使用します。

「var」を使用するかどうかに関係なく、説明的な変数名を使用します。変数名は、ストレージの詳細ではなく、変数のセマンティクスを表す必要があります。「decimalRate」は悪いです。「interestRate」は良いです。

コードでのvarの使用のほとんどはおそらく大丈夫だと思います。読み取るビットにvarを使用しないでよいと思います...

var tweetReady = workouts [ ... ]

...多分、それが何であるかが100％すぐにわかるわけではないかもしれませんが、それでも私はそれがaであることをかなり早く知っていbooleanます。

この部分の変数の使用...

var listOfTweets = new List<string>();

... varの適切な使用方法とまったく同じように見えます。なぜなら、次のことを行うのは冗長だと思うからです

List<string> listOfTweets = new List<string>();

Ericが言ったことに基づいていますが、変数はおそらくlistOfTweetsではなくツイートでなければなりません。

varここですべての使用を変更する理由は何でしょうか？このコードに何か間違っていることがありますか？

language-design visual-studio

— ローワン・フリーマン
ソース

スクリーンショットのコードは、var ...を使用すべきではないことに同意するものです。

— テラスティン

varここのすべての使用は問題ないと思います。変更することもできますが、それでも必要ではないと思います。なぜそれらをすべて明示的な型に変更するのですか？

— ローワンフリーマン

人間にとって明らかなことは、ビジュアルスタジオにとって必ずしも明白ではないことに注意してください。

— candied_orange

すべて？スクリーンショットには、明らかに変数に関連するエラーが1つあります。

— テラスティン

まあ、それ自体はエラーではなく、リンターが指摘するような種類の警告です。画像によると、すべてがvars同じ方法でマークされています。それらの横に同じ警告の十字マークと赤い下線が付いています。おそらくVisual Studioは、すべてを同じ方法で修正したいと考えています。誤解しない限り。

— ローワンフリーマン

回答:

TL; DR：いいえ、MicrosoftはC＃での 'var'の使用を推奨していません。この画像には、文句を言う理由を説明するためのコンテキストが欠けているだけです。

VS2017 RCをインストールし、オプションパネルを開いてに移動するText Editor -> C#と、新しいセクションが表示されますCode Style。これは、ReSharperがしばらく提供してきたものに似ています：コーディングスタイルの設定可能なルールのセット。

の使用に関する3つのオプションが含まれていますvar：組み込み型、変数の型が明らかな場合、および「Elsewhere」。いずれの場合も、「prefer explicit type」または「prefer var」を指定して、通知レベルを「none」、「suggestion」、「warning」または「error」に設定できます。

— デビッド・アルノ
ソース

デフォルトは何ですか？「工場出荷時設定」が「明示的なタイプを優先する」である場合、MSはの使用を推奨していないと主張できますvar。

— ジャックB

@JacquesB、デフォルトはスクリーンショットに示すとおりです。すべてが「なし」に設定されているため、「明示的な型を優先する」がMSの優先する方法としてアクティブに設定されているか、それが「ゼロ値」だけであるかを知ることは困難です。私のvar知る限りでは、最高の開発者はすべてを支持しているので、この問題に関してMSの見解がどうであるかはあまり気にしません。

— デビッドアルノ

読みすぎだと思います。そのため、暗黙的な型付けの使用を明示的な型注釈に置き換えることができる機能があり、そのことから、暗黙的な型付けは推奨されません。C♯をCILバイトコードにコンパイルする機能もありますが、C♯は推奨されておらず、代わりにCILバイトコードを書く必要があると結論付けますか？おそらくない。

マイクロソフトは、IDEがコードに対して持っている深い理解を単に誇示しています。スペルを記述しなくても、タイプを書くこともできます。それでおしまい。

これは、IDEのコード理解機能を誇示する良い例です。小さくて自己完結型であり（より大きなリファクタリングを示すのとは異なり）、すべてのエディションで利用でき、すべての開発者に適用できます（Ultimateでのみ使用でき、重要な部分には適用できない非常に印象的なアーキテクチャ視覚化機能の一部とは異なります） VSの潜在的なユーザーのうち、それほど大きなプロジェクトを持たないユーザー）、および非常に単純ですが（文字通り、それcsc.exe以来、文字通りまったく同じことを行っています）var導入された）、特に暗黙のタイピングと型推論を実際に理解していない人（または「型推論」をグーグルで検索しようとして、実際にはHindley-Milner、統一、バックトラッキングなどの用語で圧倒される人には、確かに印象的です） C♯のローカルのみの推論は非常に単純で単純です。

つまり、要するに、これはIDE機能を誇示する派手な方法です。

— ヨルグ・W・ミッターク
ソース