C# コーディングガイドライン 2013/02/26

Coding Guidelines for C# 3.0,
4.0 and 5.0 のご紹介
尾崎義尚 @yoshioms
2013.2.25

 aviva SolutionsのDennis Doomenさんが公
開しているコーディングガイドライン
 aviva Solutions
 オランダにあるコンサルティング会社
 ソフトウェア開発のコンサルティング
もやってるらしい

http://csharpguidelines.codeplex.com/releases/view/98254

C# コーディングガイドライン日本語版

翻訳することになった経緯

 もう10年以上前のもので内容が古くなっている
 欲しい情報が不足している

 不要な情報が含まれている

C# コーディングガイドラインの一例 1/2

 そもそも情報が少なすぎる
 4ページしかない

 っていうか、命名規約しかない。

https://docs.google.com/presentation/d/1ajbucKh09cSD_N3m5iUV9jBi7Ji34QczxD6xnjwfcIo/edit

C# コーディングガイドラインの一例 2/2

時代に合わせた
コーディング標準が
必要！

連絡・交渉翻訳

翻訳レビュー公開

公開までのスケジュール

Dennis さんに日本語訳を打診
• 将来、更新したらすぐに翻訳すること。
• そのまま訳す（literal translation）ならCodePlexでホスト
します。
• もし変更して独自のものを作るのであれば、インターネッ
トに公開してはいけません。
ただし明らかに日本の文化に合わないものがあれば(if you
think that makes sense) 若干の変更してもかまいません。

連絡・交渉

 小島富治雄さん
 原敬一さん
 かるあくんさん
 岩永伸之さん
 青木淳夫さん
 赤澤光世さん
 長沢隆さん
 小山康晴さん

特に岩永さんのレビューがすごかった！

レビュー

 Kokudoriさんの読評がすご
い！

http://d.hatena.ne.jp/Kokudori/20130214/1360868503

さまざまな反響

 重要度に応じて必要な規約を選択する
❶ 絶対に守るべきガイドライン
❷ 強くお薦めするガイドライン
❸ 状況に応じては推奨するガイドライン

文書の基本構造

全部を採用する必要は
ありません。
プロジェクトにあった
選択を。

 クラスやインターフェイスはそれが参加しているシステム
の中で単一の目的を持つべきである。
 一般的にクラスは以下の2つに分類できる。
 emailやISBNのようなプリミティブ型、業務を抽象化し
たもの、プレーンなデータ構造
 もしくは、複数のクラス間での対話によるオーケスト
レーションを行う責任があるもの
 それらが組み合わさることはない。このルールは、SOLID
原則のひとつである単一責務の原則として知られている。
 Tipクラスの意図を伝えるためにデザインパターンを使用す
る。もしひとつのデザインパターンを割り当てることがで
きない場合、ひとつ以上のことをしようとしている可能性
がある。
AV1000

クラスやインターフェイスはひとつの役割だけを持つようにする

 new キーワードは、ポリモーフィズムを壊す
 サブクラスを理解することがより難しくなる。
public class Book
{
public virtual void Print()
{
Console.WriteLine("Printing Book");
}
}
public class PocketBook : Book
{
public new void Print()
{
Console.WriteLine("Printing PocketBook");
}
}

PocketBook pocketBook = new PocketBook();

pocketBook.Print(); // "Printing PocketBook "と出力される
((Book)pocketBook).Print(); // "Printing Book"と出力される
AV1010

継承メンバーを newキーワードで隠すべきではない

 ベースクラスがサブクラスに依存すると、
 適切なオブジェクト指向設計に反する

 新しい派生クラスを追加することを阻む

AV1013

ベースクラスから派生クラスを参照しない

 2つのクラスがお互いに依存し合っている
 どちらかの変更がもう一方に影響を与える
 依存性をなくすには：一方のクラスのインターフェイスに
依存性注入を使用する
 例外ドメイン駆動設計で定義されたドメインモデル
 実生活の関係性によって双方向の関係になることがある。
 本当に必要かどうかを確認して、それでも必要な場合は
それを維持する。

AV1020

双方向の依存を避ける

 振る舞いだけを持つ（静的な）クラスがある場合、それが
適用されるデータの近くにロジックを移動する。
 例外
 データ転送オブジェクト（Data Transfer Objects)
 メソッドのパラメータをラップするクラス

AV1025

クラスは状態と振る舞いを持つべきである

 プロパティは、他のプロパティに対してステートレスでな
くてはならない。
プロパティの後でDataMemberをセットした
 DataSource
場合とその逆で差があってはいけない。

AV1100

プロパティはあらゆる順番でセットできるようにする

 1つの型に2つの相反するコンセプトを持っている
 ドメインモデルでよく見られる

AV1110

相互排他なプロパティを使用しない

 nullではなく、空のコレクションや空文字列を返すようにする

AV1135

文字列やコレクションのプロパティ、メソッド、引数はnullであってはなら
ない

 Exception、SystemExceptionなどでキャッチしない
 トップレベルのコードでは、きちんとキャッチしてログを
はいて、終了する。

AV1210

汎用的な例外キャッチでエラーを飲み込まない

 イベントのサブスクライバが存在しない場合nullになるた
め、呼び出す前にデリゲートリストであるイベント変数が
nullでないことを確認する
event EventHandler<NotifyEventArgs> Notify;

void RaiseNotifyEvent(NotifyEventArgs args)
{
EventHandler<NotifyEventArgs> handlers = Notify;
if (handlers != null)
{
handlers(this, args);
}
}

AV1220

常にイベントハンドラのnullをチェックする

 イベントハンドラーのsender引数は、イベントソースを識
別するために使用される
 通常はthisを渡せばよい
 イベントデータがない場合は、EventArgs.Emptyを渡す
 例外静的イベントでは、sender引数はnullでなくてはなら
ない。

AV1235

イベントを発生させる時sender 引数としてnullを渡すべきではない

 以下のコードスニペットを考えてみよう
public IEnumerable<GoldMember> GetGoldMemberCustomers()
{
const decimal GoldMemberThresholdInEuro = 1000000;
var q = from customer in db.Customers
where customer.Balance > GoldMemberThresholdInEuro
select new GoldMember(customer.Name, customer.Balance);

return q;
}

 qは上記のクエリを表現する式木を返す
 代わりにToList()やToArray()などのメソッドを使ってLINQクエリの結果を明示的に
評価する。

AV1250

LINQ式を戻り値として返す前に評価する

 7個より多いステートメントを持つメソッドは、多くのこ
とをし過ぎているか、多くの責任を持ちすぎている。
 コードが何をしているかを理解するために人が正確にス
テートメントを分析する必要があります。
 内容を説明した名前を持つ、複数の小さく、フォーカスさ
れたメソッドに分割して、それでも高いレベルでアルゴリ
ズムがまだ明確であることを確認する。

AV1500

メソッドは7ステートメントを超えるべきではない

 最初はスコープを可能な限り狭める。
 その後慎重になにをpublicメンバーや型として公開するか
を決める。

AV1501

デフォルトでは、すべてのメンバーをprivateに、型をinternalにする

 記号定数以外に数値、文字列のどちらにもリテラル値を使用してはいけない。
例えば: public class Whatever
{
public static readonly Color PapayaWhip = new Color(0xFFEFD5);
public const int MaxNumberOfWheels = 18;
}

 ログやトレースのための文字列はこのルールから除外する。文脈から意味が明
確な場合と将来変更される可能性がない場合にはリテラルを許可する。
例えば: mean = (a + b) / 2; // OK
WaitMilliseconds(waitTimeInSeconds * 1000); // 十分明確である

 ある定数が他に依存している場合は、コード内で明示するようにする。
public class SomeSpecialContainer
{
public const int MaxItems = 32;
public const int HighWaterMark = 3 * MaxItems / 4; // at 75%
}

 Note 記号定数を明らかにするために列挙型を使用することができる
AV1515

“マジック” ナンバーを使ってはいけない

 LINQクエリの結果やステートメントからの型が確実に明確なと
きには、varを使うことによって可読性が向上する。そのため、
以下のようには使用しない。
var i = 3; // 型はなに？ int? uint? float?
var myfoo = MyFactoryMethod.Create("arg"); // なにを期待しているのかが明確じゃない。
// ベースクラス? インターフェイス?
// また、クラスを探すことができないと
// リファクタリングが難しくなる
 var は、以下のように使用する。
var q = from order in orders where order.Items > 10 and order.TotalValue > 1000;
var repository = new RepositoryFactory.Get<IOrderRepository>();
var list = new ReadOnlyCollection<string>();

 上記3つの例では、期待している型が明確である。より詳細な
varによるメリット・デメリットは、Eric Lippert氏の型推論を
使うかどうかを参照して欲しい。

AV1520

型が確実に明確なときにだけvarを使用する

 通常はbool型の式でtrue かfalseかを比較するためことはよ
くないスタイルである。例えば:
while (condition == false) // 間違えた、よくないスタイル
while (condition != true) // これも誤り
while (((condition == true) == true) == true) // どこまでいくの？
while (condition) // OK

AV1525

true やfalse を明示的に比較しない

 Defaultブロックが空の場合は説明するコメントを追加する
 到達することがない場合は、InvalidOperationExceptionを
スローする
void Foo(string answer)
{
switch (answer)
{
case "no":
Console.WriteLine("You answered with No");
break;
case "yes":
Console.WriteLine("You answered with Yes");
break;
default:
// ここで終わることはない。
throw new InvalidOperationException("Unexpected answer " + answer);
}
}

AV1536
常にswitch ステートメントの最後のcase の後にdefaultブロックを
追加する

 以下の例について考えてみよう
if (member.HidesBaseClassMember && (member.NodeType != NodeType.InstanceInitializer))
{
// なにかをする
}

 この表現を理解するためには、詳細とすべての結果で、な
にをしているのかを分析する必要がある。明らかに、上に
コメントを追加することができるが、それよりも明確な名
前のメソッド名でこの複雑な表現を起きえる方がよいだろ
う: if (NonConstructorMemberUsesNewKeyword(member))
{
// なにかをする
}

private bool NonConstructorMemberUsesNewKeyword(Member member)
{
return
(member.HidesBaseClassMember &&
(member.NodeType != NodeType.InstanceInitializer)
} AV1547

メソッドやプロパティの複雑な表現をカプセル化する

 C# 4.0でオプショナル引数を使用する唯一の妥当な理由は、ひとつの
メソッドで以下のようにルールAV1551 の例を置き換えることである:
public virtual int IndexOf(string phrase, int startIndex = 0, int count = 0)
{
return someText.IndexOf(phrase, startIndex, count);
}

 オプショナルパラメータが参照型の場合、デフォルト値はnullしか与え
られない。しかしここで、string、リスト、コレクションの場合は、
ルールAV1235によりnullであってはならないため、代わりにオーバー
ロードされたメソッドを使用する必要がある。
 Note オプショナルパラメータのデフォルト値は、呼び出し側に保存さ
れている。呼び出し側のコードを再コンパイルしないでデフォルト値
を変更すると、新しいデフォルト値プロパティは適用されない。
 Note インターフェイスメソッドがオプショナルパラメータを定義して
いる場合、インターフェイスの参照を通じてクラスの実態を呼び出さ
ない限り、デフォルト値はオーバーロードの解決時に考慮されない。
詳細は、Eric Lippert氏のこの投稿を参照。

AV1553

オプショナル引数は、オーバーロードを置き換えるためにだけ使用
する

 C# 4.0の名前付き引数は、大量のオプショナルパラメータ
を提供するCOMコンポーネントの呼び出しを簡単にするた
めに導入された。
 メソッド呼び出しの可読性を改善するために名前付き引数
が必要なら、そのメソッドはおそらく多くのことをやり過
ぎているか、リファクタリングすべきである。
 名前付き引数で可読性が改善する唯一の例外は、有効なオ
ブジェクトを生み出すコンストラクターで以下のように呼
ばれたときだ:
Person person = new Person
(
firstName: "John",
lastName: "Smith",
dateOfBirth: new DateTime(1970, 1, 1)
);

AV1555

名前付き引数の使用を避ける

 メソッドが3つより多いパラメータを必要とする場合、
Specificationデザインパターンで説明されているように、
複数の引数を渡すための構造体かクラスを使用する。一般
的にパラメータ数が少ないほうがメソッドを理解しやすい。
さらに、多くのパラメータが必要なメソッドのユニットテ
ストには多くのシナリオが必要になる。

AV1561

3つより多いパラメータを受け取るメソッドやコンストラク
ターを許可しない

 これらはコードを理解しづらくして、バグを引き起こすこ
とがある。代わりに複合オブジェクトを返すようにする。

AV1562

ref やout パラメータを使用しない

 オブジェクトからインターフェイスの参照を取得するため
にasを使っている場合、その操作がnullを返さないかを常
に確認する。
 オブジェクトがインターフェイスを実装していないときに
これを怠ると、ずっと後の段階でNullReferenceException
が発生することがある。

AV1570

常に as 操作の結果をチェックする

 コメントアウトされたコードをチェックインしない
 やるべき作業を管理できる作業アイテムをトラックできる
システムを使用する
 コメントアウトされたコードをみつけたときになにをする
べきかを誰もわからない
 テストのために一時的に無効化している？サンプルをコ
ピーした？そんなものは削除するべきだ。

AV1575

コードをコメントアウトしない

 英語を使用する場合、すべての型メンバー、パラメータ、変数
はアメリカ英語の単語を使用するべきである。
 簡単で読みやすく、文法として正しい名前を選択する。例えば、
HorizontalAlignmentはAlignmentHorizontalよりも読みやすい
 短さよりも読みやすさを選ぶ。CanScrollHorizontallyというプロ
パティ名はScrollableX よりも優れている（X軸はあいまいな参照
である）
 プログラム言語で広く使われているキーワードとの衝突を避け
る
 例外ほとんどのプロジェクトでは、ドメインや企業に固有の単
語やフレーズを使用する。Visual Studioの静的コード分析は、す
べてのコードにスペルチェックを実行するため、カスタムコー
ド分析辞書に用語を追加する必要がある。
AV1701

アメリカ英語を使用する

言語要素ケース例
クラス、構造体 Pascal AppDomain
インターフェイス Pascal IBusinessService
列挙型 Pascal ErrorLevel
列挙値 Pascal FatalError
イベント Pascal Click
Privateフィールド Camel listItem
Protectedフィールド Pascal MainPanel
Constフィールド Pascal MaximumItems
Const変数 Camel maximumItems
Read-only静的フィールド Pascal RedValue
変数 Camel listOfValues
メソッド Pascal ToString
名前空間 Pascal System.Drawing
パラメータ Camel typeName
型パラメータ Pascal TView
プロパティ Pascal BackColor AV1702

言語要素に適したケースを使用する

 例えば、静的フィールドかどうかを区別するためにg_ や
s_ を使用してはいけない
 一般的にローカル変数かメンバー変数かの区別がつかない
場合、大きすぎることが多い
 正しくない識別子名には次のようなものがある:
_currentUser, mUserName, m_loginTime

AV1705

フィールドにプレフィックスを使用しない

class Employee
{
// 誤り!
static GetEmployee() {}
DeleteEmployee() {}

// 正しい
static Get() {...}
Delete() {...}

// これも正しい
AddNewJob() {...}
RegisterForMeeting() {...}
}

AV1710

クラスや列挙型のメンバーは、名前を繰り返えさない

 以下のステートメントは、技術的には正しいが混乱する可
能性が非常に高い
bool b001 = (lo == l0) ? (I1 == 11) : (lOl != 101);

AV1712

短い名前や他の名前と間違えられることがある名前は避ける

 例えば、Objectの代わりにobject、Stringの代わりにstring、
Int32の代わりにint
 これらのエイリアスはプリミティブ型としてC#言語の一級
市民として提供されているため、これらを使用するべきで
ある
 例外これらの型の静的メンバーを参照するときは、完全な
CLS名を使用する。例えば、int.Parse()の代わりに
Int32.Parse()

AV2201

System名前空間の型ではなく、C#の型エイリアスを使用する

 開発環境で、C#コンパイラの警告レベル 4で構成し、警告
をエラーとして扱うオプションを有効にする
 これはコンパイラに可能な限り最高のコード品質を強要す
ることができる。

AV2210

最も高い警告レベルでビルドする

 dynamicキーワードは、動的言語で作業するために導入さ
れた。コンパイラがいくつかの複雑なリフレクションコー
ドを生成する必要があるため、これを使うことで深刻なパ
フォーマンスのボトルネックになる可能性がある。
 これは、(Activatorを使って)動的に生成されたインスタン
スのメソッドやメンバーを呼び出すときだけ、
Type.GetProperty() 、Type.GetMethod()、COM互換型とし
て操作する代わりに使用する

AV2230

dynamicキーワードは動的オブジェクトを受け取るときだ
け使用する

AV2301

コメントとドキュメントをアメリカ英語で記述する

 コメントには「どのように(how)」ではなく、コードブ
ロックの「なぜ(Why)」と「なに(What)」にフォーカスす
る。ステートメントを言葉で説明するのを避け、なぜ
(Why)そのソリューションやアルゴリズムを選択して、な
に(What)を達成しようとしたのかを読み手が理解すること
を助けよ。明確なソリューションで問題が発生したなどの
理由で代替手段を選んだのであれば、そのことについて触
れること。

AV2316

複雑なアルゴリズムや決定を説明するコメントのみを記述
する

 1行を130文字以内に抑える
 4文字の空白インデントを使用して、タブを使用しない
 ifと式の間のようにキーワード間に空白をひとつ入れるが、
if (condition == null) のようにその前後には空白を追加し
ない
 +、-、==など、演算子の周りに空白を追加する
 言語的に必要なかったとしても、if、 else、 do、 while、
for、 foreachなどに開始と終了の括弧を置いて、常にキー
ワードを成功させる。
 開始と終了の括弧は常に新しい行に置く

AV2400

一般的なレイアウトを使用する

 オブジェクト初期化子と各プロパティの初期化は、以下の
ようにインデントせず、新しい行に書く:
var dto = new ConsumerDto()
{
Id = 123,
Name = “Microsoft”,
PartnerShip = PartnerShip.Gold,
}

 ブロックを持つラムダ式は、インデントせず、以下のよう
に書く:

methodThatTakesAnAction.Do(x =>
{
// なにかする
}

AV2400


 クエリ式は、以下のように全体を1行にするか、各キーワードを同じイ
ンデントにする:
var query = from product in products where product.Price > 10 select product;

 または
var query =
from product in products
where product.Price > 10
select product;

 LINQステートメントは必ず、from 句から始めて、where句でそれを混
ぜ込まない
 すべての比較条件の周りに括弧を追加するが、単数の条件の周りには
括弧を追加しない。例えば、
 if (!string.IsNullOrEmpty(str) && (str != “new”)) != “new”))
if (!string.IsNullOrEmpty(str) && (str

 複数行のステートメントの間、メンバーの間、閉じ括弧の後、無関係
のコードブロック、#regionキーワードの周り、異なる会社のusingス
テートメントの間には空行を追加する。

AV2400


 共通の並び順を維持することで、他のチームメンバーが簡単に
コードで目的のものを見つけることができる。一般的にソース
ファイルは、本を読むように上から下に読むことができるべき
である。これは読者がコードファイルで上下に行き来しなけれ
ばいけない状況を防ぐ。
 privateフィールドと（領域の）定数
 public定数
 public readonly static フィールド
 ファクトリメソッド
 コンストラクターとファイナライザー
 イベント
 publicプロパティ
 呼び出す順で、その他のメソッドとprivateプロパティ
AV2406

メンバーを適切に定義された並び順にする

 Regionは便利なときもあるが、クラスの主な目的を隠すこ
ともできてしまう。従って#regionは、以下の目的でのみ使
用する:
 privateフィールドと定数（できればprivate定義region）
 ネストされたクラス
 インターフェイスの実装（インターフェイスがそのクラス
の主な目的でない場合のみ）

AV2407

#regionを控える

C# コーディングガイドライン 2013/02/26

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to C# コーディングガイドライン 2013/02/26

Similar to C# コーディングガイドライン 2013/02/26 (20)

More from Yoshihisa Ozaki

More from Yoshihisa Ozaki (12)

Recently uploaded

Recently uploaded (12)

C# コーディングガイドライン 2013/02/26