コード分​​析では、＆＃8220; out＆＃8221;を使用しないという提案があります。パラメーター

Question

作成したオブジェクトに対してVS 2008コード分析ツールを実行し、次の提案を受けました...

  

警告147 CA1021：Microsoft.Design   ：しない設計を検討する   「returnValue」がアウトであることを要求する   パラメータ。

＆quot; out＆quot;が見つかりましたパラメータはかなり有用であり、それらが設計慣行で眉をひそめられていると見なされたことを認識していませんでした。この警告を受けた理由を誰かが明らかにすることができるかどうか知りたいですか？それが悪い習慣である場合は？どうして？そして、何が良い習慣でしょうか？

アドバイスをお願いします。

Answer 1

すべてのコード分析警告には、警告を強調表示して F1 を押すとアクセスできるドキュメントが関連付けられています。アイテムを右クリックしてヘルプを表示することもできます。

いずれの場合でも、その特定の警告を説明するドキュメント 。

outパラメータがまだ良い選択である場合がいくつかあると思います-特にTryParseコーディングイディオムに関しては、ほとんどの人が理解していることを行うための確立された方法なので、

ただし、一般的な使用では、複数の戻り値に対するより優れたオブジェクト指向のソリューションがあります。

Answer 2

プロジェクトでコード分析を実行したことがあります。また、私は多くの洞察に満ちた提案を得ました、私はこれを非常に簡潔にオフにしました。提案の多くは宗教的なものであり、あなたはこのように、または他の方法でそれを行うことができ、スタイルの問題であり、悪い習慣ではありません。

あなたの状況に。戻りパラメーターが1つしかない場合は、関数から返してください。

戻り場所を占める戻りコードもある場合は、例外を使用して呼び出し元のコードに操作エラーを通知することを検討してください。

互いに密接に関連する返されるパラメータが多数ある場合は、それらをまとめて保持するクラス/構造を作成し、パックとして返します。

Answer 3

コード分析の警告の多くは、サードパーティが使用するAPIコードの記述に関連しているように思われます。 「出力」パラメータを使用するルールは古典的なケースです。それらを使用しない理由の一部は、他の多くのプログラマがそれらについて知らないためです。

あなたが書いているものと一致しない場合は、あなたに合わないコード分析ルールをオフにしてください。 個人的には、作成するコードの種類に関係がないため、命名規則、移植性規則、相互運用性規則をオフにする傾向があります。

Answer 4

ほとんどのプロジェクトでこの特定の警告をオフにしました。 なぜなら、outパラメーターを使用する場合、それらを完全に回避しようとするため、使用する正当な理由があるからです。

しかし、プロジェクトで複数の人と作業しているときに、コードレビューを行いたい場合は、この警告をオンにすることを想像できます...