web-dev-qa-db-ja.com

コーディングガイドライン+ベストプラクティス?

クエリに直接当てはまる質問が見つからなかったので、これを新しい質問として投稿します。私を助けるかもしれない既存の議論があれば、それを指摘して質問を閉じてください。

質問:

C#コーディングガイドラインについてプレゼンテーションを行いますが、コーディング標準に限定されるものではありません。

ですから、大まかな考えはありますが、優れたプログラミング手法に取り組む必要があると思います。なので内容はこんな感じになります。

  1. 基本的なコーディング標準-ケーシング、フォーマットなど。

  2. グッドプラクティス-他のデータ構造に対するハッシュセットの使用、文字列と文字列ビルダー、文字列の不変性とそれらの効果的な使用など

本当に私はもっと良い習慣を追加したいと思います(特にパフォーマンスを改善するために)。それで、C#で使用されるいくつかの良い習慣を聞きたいです。助言がありますか??? (大きな説明は必要ありません:)アイデアだけで十分です。)

21
Mitch Wheat

ここにいくつかのヒントがあります:

  1. 静的分析にはFxCopを使用します。
  2. コーディングスタイルの検証にはStyleCopを使用します。
  3. 値型のセマンティクスが異なるため、IDE(go to Tools/Options/Environment/Fonts and Colors/Display Items and供給ユーザータイプ(列挙型)およびユーザータイプ(値タイプ)#DF7120 [223、113、32])のような値。
  4. 例外はコードにバグを表示する傾向があるため、IDEすべての例外で中断させます。(デバッグ/例外... /共通言語ランタイム例外に移動してチェックします) スロー)。
  5. プロジェクト設定:安全でないコードを禁止します。
  6. プロジェクト設定:エラーとしての脅威警告。
  7. プロジェクト設定:算術オーバーフロー/アンダーフローを確認します。
  8. 明確に定義された単一の目標に変数を使用します。
  9. マジックナンバーは使用しないでください。
  10. 短いメソッドを記述します。メソッドには、1レベルの抽象化のみを含める必要があります。
  11. メソッドが小さすぎることはありません(20行のメソッドはかなり大きいと見なされます)。
  12. メソッドは、不正な入力から自身を保護する必要があります。
  13. 型を不変にすることを検討してください。
  14. プラグマ警告を無効にして、コード内の警告を抑制しないでください。
  15. 悪いコードにコメントしないでください:それを書き直してください。
  16. 例外を飲み込む理由をコードで明示的に文書化します。
  17. 文字列を連結することのパフォーマンスへの影響に注意してください。
  18. Gotoステートメントは絶対に使用しないでください。
  19. 早く失敗し、早く失敗します。
10
Steven

私はMicrosoftの クラスライブラリを開発するための設計ガイドライン を使用しています。そして、私は最初からかなり良いと思います。

4
Regent
  • 基本的なコーディング標準-一貫していることを確認してください。 msdnに関するこのドキュメント に記載されている規則に従わない場合でも。ここでは一貫性が本当に重要だと思います。

  • ユニットテスト-ここで間違いはありません。

  • セキュリティ-機密データを渡す場合に安全であることを確認することについて話します。

  • パフォーマンス-ご存知のように、私は個人的に、アプリケーションを正しく取得してからパフォーマンスを確認することが私がしていることだと感じています。私はコードを書くときにそれを心の奥底に持っているので、最後に来るのは少し微調整です。

1