作成したオブジェクトに対してVS2008コード分析ツールを実行し、次の提案を受け取りました...
警告147CA1021：Microsoft.Design：'returnValue'がoutパラメーターである必要のない設計を検討してください。
私は「アウト」パラメータがかなり有用であることに気づき、それらが設計の実践で眉をひそめていると見なされていることに気づいていませんでした。私がこの警告を受け取った理由について誰かが光を当てることができるかどうか知りたいと思いましたか？それが悪い習慣なら？なぜ？そして、何が良い習慣でしょうか？
アドバイスをいただければ幸いです。
すべてのコード分析警告には、警告を強調表示してF1キーを押すことでアクセスできるドキュメントが関連付けられています。アイテムを右クリックしてヘルプを表示することもできます。
いずれにせよ、ここにその特定の警告を説明するドキュメントがあります。
アウトパラメータがまだ良い選択である場合がいくつかあると思います。特に、TryParseコーディングイディオムに関しては、ほとんどの人が理解しているはずの非常に確立された方法であるためです。
ただし、一般的には、複数の戻り値に対して、より優れた、よりオブジェクト指向のソリューションがあります。
コード分析の警告の多くは、サードパーティが使用するAPIコードの記述に関連しているように思われます。'out'パラメーターを使用したルールは、典型的なケースです。パラメーターを使用しない理由の1つは、他の多くのプログラマーがパラメーターについて知らないためです。
それらがあなたが書いているものと一致しない場合は、あなたに合わないコード分析ルールをオフにしてください。個人的には、名前付け、移植性、相互運用性のルールは、自分が作成するコードの種類とは関係がないため、オフにする傾向があります。
私はかつて自分のプロジェクトでコード分析を実行しました。また、私は多くの洞察に満ちた提案を得ました、私はこれを非常に簡単にオフにしました。提案の多くは宗教的な性質のものであり、あなたはそれをこの方法または他の方法で行うことができます。スタイルの問題であり、悪い習慣ではありません。
あなたの状況に。戻りパラメーターが1つしかない場合は、それを関数から戻します。
戻り場所を占める戻りコードもある場合は、例外を使用して呼び出し元のコードに操作エラーを通知することを検討してください。
互いに密接に関連する返されるパラメータが多数ある場合は、それらをまとめて保持するクラス/構造を作成し、パックとして返します。
ほとんどのプロジェクトで、この特定の警告をオフにしました。なぜなら、outパラメーターを使用するときは、それらを完全に回避しようとするので、そうする正当な理由があることを私は知っています。
プロジェクトで複数の人と作業しているときに、コードレビューを行いたい場合は、この警告をオンにすることをお勧めします...