C#で開発を行う際に守るべき18のルール

StackOverFlowで紹介されていたC#で開発を行う際に守るべき18のルールが紹介されていました。
内容が興味深かったので紹介します。
元ネタは、http://stackoverflow.com/questions/2787035/coding-guidelines-best-practicesです。

日本語に訳していますが、意味いまいちな場合は原文を当たった方が分かりやすいかも…

1.FxCopを使用して、ソースの静的チェックを行う

FxCopとは、Framework Copの略で(Cop=警察です)、Microsoftから提供されているツールです。
コンパイル後のバイナリ(マネージドコードアセンブリ)に対して、ガイドラインに準拠しているかをチェックする事ができます。

2.StyleCopを使用してコードのスタイルをチェックする

StyleCopは、ソースコードのスタイルをチェックする事ができます。
コーディング規約のチェックに便利です。
http://archive.msdn.microsoft.com/sourceanalysis

3.値の型(value type)がEnumと異なる意味である事を示すために、IDEの設定で色を変更せよ。

VisualStudioのメニューバーの、ツール->オプション->環境->フォントおよび色をみると、ユーザタイプ(列挙型)と、 ユーザタイプ(値の型)が同じ色になっているので、一方を違う色に変更して置きます。
これによって、列挙型と、Value Typeの区別が付きやすくなります。

4.例外はコード内のバグを示す傾向があるため、IDEで全ての例外をbreakさせるようにせよ。

VisualStudioのメニューバーの、デバッグ->例外で、Common Language Runtime Exceptionsの”スローされるとき”にチェックを入れます。
これで、デバッグ中にCLRの例外が発生すると、常にプログラムの実行が中断されます。

5.プロジェクトの設定で、”アンセーフコードを許可しない”の設定をセよ

VisualStudioのメニューバーより、プロジェクト->ｘｘｘのプロパティを選択後、ビルドタブで指定できます。

6.プロジェクトの設定で、”警告をエラーとして扱う”の設定をセよ

VisualStudioのメニューバーより、プロジェクト->ｘｘｘのプロパティを選択後、ビルドタブで指定できます。

7.プロジェクトの設定で、演算のオーバーフローおよびアンダーフローのチェックを入れよ

VisualStudioのメニューバーより、プロジェクト->ｘｘｘのプロパティを選択後、ビルドタブに有る”詳細設定”ボタンより指定できます。

8.単一で明確に定義された目的のために変数を使用せよ。

1つの変数を複数の目的で使用すると、後でコードをメンテするときにバグが入りやすくなってしまいます。

9.マジックナンバーを使用するな。

マジックナンバーというのは、コード中に書かれた具体的な数字です。

数字をコード中に直接書くのではなくconstを使用して、定数を定義します。
http://msdn.microsoft.com/ja-jp/library/ms173119%28v=vs.80%29.aspx

10.1つのメソッドは短くなるようにせよ。単一の明確に定義された目的を持たせるべき。

複数の処理が混在している複雑なメソッドは、バグが入りやすくなりますし、仕様が変わったとき場合にもメンテを行う範囲が大きくなってしまう場合が多いため保守性の面でも問題があります。

11.メソッドは小さすぎるということは無い(1メソッドが20行を超えると、大きいと思え)

10.と同じような意味かと思います。
1つの処理はなるべくシンプルにしておき、モジュール間の結合が小さくなる事を心がけます。

12.メソッドのパラメータとして、不正な値をはじくようにチェックせよ

不正な値は、入ってきたタイミングで防ぐ事でプログラムの品質を向上する事ができます。
メソッドのパラメータは処理の最初でチェックを行い、NGの場合は例外を返す等の処理を行います。

13.オブジェクトを不変(immutable)にできないか考慮せよ

immutableについては、下記のサイトが詳しいです。
immutable

14.”#pragma warning disable”を使用して、警告の出力を抑制させてはならない。

警告はプログラムのバグを示唆してくれる場合が多いため、覆い隠すのではなく警告が出ないような表記に書き換えます。

15.ダメなコードは書き直せ

保守性を考えて、読みづらかったり、入力チェックが甘いようなロジックは書き直してしまいます。
…ただ、一方で、”動いているコードは直すな”という格言もあるので、ケースバイケースで考えてください。

16.例外をcatchして、その後の処理を正常処理する場合は、なぜそうするのか理由をコード上に明記せよ

例外を無視する場合、コーディングしている時はそうすべき明確な理由があったかもしれませんが、後から保守する時にはその意図が分からなくなっている危険が有ります。
もし、あえて無視する必要があるなら”コード中”に理由を明記しておきます。

17.文字列連活に関するパフォーマンス低下に気をつけよ。

C#に限らずjavaでも有名な話ですが”+”演算子による文字列結合を大量に行うと、パフォーマンスが低下します。このような場合はStringBuilderの使用を検討してください。

18.gotoは使用するな

goto批判については、Wikipediaを参照してください。
http://ja.wikipedia.org/wiki/Goto%E6%96%87

ただ、C#の場合は、Javaと違ってラベル付きcontinue/breakの構文が無いので、gotoを書いた方がすっきりする場合もあるかも…という気もします。



C#ルールブック　~読みやすく効率的なコードの原則