Coding Guidelines for C# 3.0,4.0 and 5.0 のご紹介              尾崎 義尚 @yoshioms                     2013.2.25
   aviva SolutionsのDennis Doomenさんが公                                       開しているコーディング ガイドライン                            ...
翻訳することになった経緯
   もう10年以上前のもので内容が古くなっている     欲しい情報が不足している     不要な情報が含まれている         C# コーディングガイドラインの一例 1/2
   そもそも情報が少なすぎる                                                      4ページしかない                                           ...
時代に合わせたコーディング標準が必要!
連絡・交渉    翻訳翻訳     レビュー   公開     公開までのスケジュール
Dennis さんに日本語訳を打診•   将来、更新したらすぐに翻訳すること。•   そのまま訳す(literal translation)ならCodePlexでホスト    します。•   もし変更して独自のものを作るのであれば、インターネッ...
   小島 富治雄さん   原 敬一さん   かるあくんさん   岩永 伸之さん   青木 淳夫さん   赤澤 光世さん   長沢 隆さん   小山 康晴さん               特に岩永さんのレビューがすごかった!  ...
   Kokudoriさんの読評がすご                                                         い!http://d.hatena.ne.jp/Kokudori/20130214/136...
   重要度に応じて必要な規約を選択する    ❶ 絶対に守るべきガイドライン    ❷ 強くお薦めするガイドライン    ❸ 状況に応じては推奨するガイドライン                 文書の基本構造
全部を採用する必要はありません。プロジェクトにあった選択を。
   クラスやインターフェイスはそれが参加しているシステム    の中で単一の目的を持つべきである。   一般的にクラスは以下の2つに分類できる。     emailやISBNのようなプリミティブ型、業務を抽象化し      たもの、プレ...
   new キーワードは、ポリモーフィズムを壊す   サブクラスを理解することがより難しくなる。      public class Book      {        public virtual void Print()      ...
   ベースクラスがサブクラスに依存すると、     適切なオブジェクト指向設計に反する     新しい派生クラスを追加することを阻む                                 AV1013           ベー...
   2つのクラスがお互いに依存し合っている   どちらかの変更がもう一方に影響を与える   依存性をなくすには:一方のクラスのインターフェイスに    依存性注入を使用する   例外 ドメイン駆動設計で定義されたドメインモデル    ...
   振る舞いだけを持つ(静的な)クラス がある場合、それが    適用されるデータの近くにロジックを移動する。   例外     データ転送オブジェクト(Data   Transfer Objects)     メソッドのパラメータを...
   プロパティは、他のプロパティに対してステートレスでな    くてはならない。          プロパティの後でDataMemberをセットした     DataSource     場合とその逆で差があってはいけない。       ...
   1つの型に2つの相反するコンセプトを持っている   ドメインモデルでよく見られる                                AV1110             相互排他なプロパティを使用しない
   nullではなく、空のコレクションや空文字列を返すようにする                                      AV1135     文字列やコレクションのプロパティ、メソッド、引数はnullであってはなら   ...
   Exception、SystemExceptionなどでキャッチしない   トップレベルのコードでは、きちんとキャッチしてログを    はいて、終了する。                                        ...
   イベントのサブスクライバが存在しない場合nullになるた    め、呼び出す前にデリゲートリストであるイベント変数が    nullでないことを確認する    event EventHandler<NotifyEventArgs> No...
   イベントハンドラーのsender引数は、イベントソースを識    別するために使用される   通常はthisを渡せばよい   イベントデータがない場合は、EventArgs.Emptyを渡す   例外 静的イベントでは、sende...
   以下のコードスニペットを考えてみよう     public IEnumerable<GoldMember> GetGoldMemberCustomers()     {       const decimal GoldMemberThr...
   7個より多いステートメントを持つメソッドは、多くのこ    とをし過ぎているか、多くの責任を持ちすぎている。   コードが何をしているかを理解するために人が正確にス    テートメントを分析する必要があります。   内容を説明した名...
   最初はスコープを可能な限り狭める。   その後慎重になにをpublicメンバーや型として公開するか    を決める。                                         AV1501     デフォルトでは...
   記号定数以外に数値、文字列のどちらにもリテラル値を使用してはいけない。    例えば: public class Whatever           {               public static readonly Col...
   LINQクエリの結果やステートメントからの型が確実に明確なと    きには、varを使うことによって可読性が向上する。そのため、    以下のようには使用しない。    var i = 3;                       ...
   通常はbool型の式でtrue かfalseかを比較するためことはよ    くないスタイルである。例えば:    while (condition == false)                      //   間違えた、よくな...
   Defaultブロックが空の場合は説明するコメントを追加する   到達することがない場合は、InvalidOperationExceptionを    スローする     void Foo(string answer)     {  ...
   以下の例について考えてみよう        if (member.HidesBaseClassMember && (member.NodeType != NodeType.InstanceInitializer))        {  ...
   C# 4.0でオプショナル引数を使用する唯一の妥当な理由は、ひとつの    メソッドで以下のようにルールAV1551 の例を置き換えることである:    public virtual int IndexOf(string phrase,...
   C# 4.0の名前付き引数は、大量のオプショナルパラメータ    を提供するCOMコンポーネントの呼び出しを簡単にするた    めに導入された。   メソッド呼び出しの可読性を改善するために名前付き引数    が必要なら、そのメソッド...
   メソッドが3つより多いパラメータを必要とする場合、    Specificationデザインパターンで説明されているように、    複数の引数を渡すための構造体かクラスを使用する。一般    的にパラメータ数が少ないほうがメソッドを理解...
   これらはコードを理解しづらくして、バグを引き起こすこ    とがある。代わりに複合オブジェクトを返すようにする。                                  AV1562           ref やout パラ...
   オブジェクトからインターフェイスの参照を取得するため    にasを使っている場合、その操作がnullを返さないかを常    に確認する。   オブジェクトがインターフェイスを実装していないときに    これを怠ると、ずっと後の段階で...
   コメントアウトされたコードをチェックインしない   やるべき作業を管理できる作業アイテムをトラックできる    システムを使用する   コメントアウトされたコードをみつけたときになにをする    べきかを誰もわからない   テスト...
   英語を使用する場合、すべての型メンバー、パラメータ、変数    はアメリカ英語の単語を使用するべきである。   簡単で読みやすく、文法として正しい名前を選択する。例えば、    HorizontalAlignmentはAlignmen...
言語要素     ケース                         例クラス、構造体               Pascal   AppDomainインターフェイス              Pascal   IBusinessServ...
   例えば、静的フィールドかどうかを区別するためにg_ や    s_ を使用してはいけない   一般的にローカル変数かメンバー変数かの区別がつかない    場合、大きすぎることが多い   正しくない識別子名には次のようなものがある: ...
class Employee{   // 誤り!   static GetEmployee() {}   DeleteEmployee() {}    // 正しい    static Get() {...}    Delete() {...}...
   以下のステートメントは、技術的には正しいが混乱する可    能性が非常に高いbool b001 = (lo == l0) ? (I1 == 11) : (lOl != 101);                             ...
   例えば、Objectの代わりにobject、Stringの代わりにstring、    Int32の代わりにint   これらのエイリアスはプリミティブ型としてC#言語の一級    市民として提供されているため、これらを使用するべきで...
   開発環境で、C#コンパイラの警告レベル 4で構成し、警告    をエラーとして扱うオプションを有効にする   これはコンパイラに可能な限り最高のコード品質を強要す    ることができる。                        ...
   dynamicキーワードは、動的言語で作業するために導入さ    れた。コンパイラがいくつかの複雑なリフレクションコー    ドを生成する必要があるため、これを使うことで深刻なパ    フォーマンスのボトルネックになる可能性がある。 ...
AV2301コメントとドキュメントをアメリカ英語で記述する
   コメントには「どのように(how)」ではなく、コードブ    ロックの「なぜ(Why)」と「なに(What)」にフォーカスす    る。ステートメントを言葉で説明するのを避け、なぜ    (Why)そのソリューションやアルゴリズムを選択...
   1行を130文字以内に抑える   4文字の空白インデントを使用して、タブを使用しない   ifと式の間のようにキーワード間に空白をひとつ入れるが、    if (condition == null) のようにその前後には空白を追加し...
   オブジェクト初期化子と各プロパティの初期化は、以下の    ようにインデントせず、新しい行に書く:    var dto = new ConsumerDto()    {       Id = 123,       Name = “Mi...
   クエリ式は、以下のように全体を1行にするか、各キーワードを同じイ    ンデントにする:    var query = from product in products where product.Price > 10 select p...
   共通の並び順を維持することで、他のチームメンバーが簡単に    コードで目的のものを見つけることができる。一般的にソース    ファイルは、本を読むように上から下に読むことができるべき    である。これは読者がコードファイルで上下に行...
   Regionは便利なときもあるが、クラスの主な目的を隠すこ    ともできてしまう。従って#regionは、以下の目的でのみ使    用する:   privateフィールドと定数(できればprivate定義region)   ネスト...
全部を採用する必要はありません。プロジェクトにあった選択を。
Upcoming SlideShare
Loading in …5
×

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

9,979 views

Published on

C# コーディングガイドラインに関する勉強会をやりました。
議事録は以下にまとめました。
http://blog.livedoor.jp/omssys/archives/52023811.html

Published in: Technology
  • Be the first to comment

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

  1. 1. Coding Guidelines for C# 3.0,4.0 and 5.0 のご紹介 尾崎 義尚 @yoshioms 2013.2.25
  2. 2.  aviva SolutionsのDennis Doomenさんが公 開しているコーディング ガイドライン  aviva Solutions  オランダにあるコンサルティング会社  ソフトウェア開発のコンサルティング もやってるらしいhttp://csharpguidelines.codeplex.com/releases/view/98254 C# コーディング ガイドライン日本語版
  3. 3. 翻訳することになった経緯
  4. 4.  もう10年以上前のもので内容が古くなっている  欲しい情報が不足している  不要な情報が含まれている C# コーディングガイドラインの一例 1/2
  5. 5.  そもそも情報が少なすぎる  4ページしかない  っていうか、命名規約しかない。https://docs.google.com/presentation/d/1ajbucKh09cSD_N3m5iUV9jBi7Ji34QczxD6xnjwfcIo/edit C# コーディングガイドラインの一例 2/2
  6. 6. 時代に合わせたコーディング標準が必要!
  7. 7. 連絡・交渉 翻訳翻訳 レビュー 公開 公開までのスケジュール
  8. 8. Dennis さんに日本語訳を打診• 将来、更新したらすぐに翻訳すること。• そのまま訳す(literal translation)ならCodePlexでホスト します。• もし変更して独自のものを作るのであれば、インターネッ トに公開してはいけません。ただし明らかに日本の文化に合わないものがあれば(if youthink that makes sense) 若干の変更してもかまいません。 連絡・交渉
  9. 9.  小島 富治雄さん 原 敬一さん かるあくんさん 岩永 伸之さん 青木 淳夫さん 赤澤 光世さん 長沢 隆さん 小山 康晴さん 特に岩永さんのレビューがすごかった! レビュー
  10. 10.  Kokudoriさんの読評がすご い!http://d.hatena.ne.jp/Kokudori/20130214/1360868503 さまざまな反響
  11. 11.  重要度に応じて必要な規約を選択する ❶ 絶対に守るべきガイドライン ❷ 強くお薦めするガイドライン ❸ 状況に応じては推奨するガイドライン 文書の基本構造
  12. 12. 全部を採用する必要はありません。プロジェクトにあった選択を。
  13. 13.  クラスやインターフェイスはそれが参加しているシステム の中で単一の目的を持つべきである。 一般的にクラスは以下の2つに分類できる。  emailやISBNのようなプリミティブ型、業務を抽象化し たもの、プレーンなデータ構造  もしくは、複数のクラス間での対話によるオーケスト レーションを行う責任があるもの それらが組み合わさることはない。このルールは、SOLID 原則のひとつである単一責務の原則として知られている。 Tipクラスの意図を伝えるためにデザインパターンを使用す る。もしひとつのデザインパターンを割り当てることがで きない場合、ひとつ以上のことをしようとしている可能性 がある。 AV1000 クラスやインターフェイスはひとつの役割だけを持つようにする
  14. 14.  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キーワードで隠すべきではない
  15. 15.  ベースクラスがサブクラスに依存すると、  適切なオブジェクト指向設計に反する  新しい派生クラスを追加することを阻む AV1013 ベースクラスから派生クラスを参照しない
  16. 16.  2つのクラスがお互いに依存し合っている どちらかの変更がもう一方に影響を与える 依存性をなくすには:一方のクラスのインターフェイスに 依存性注入を使用する 例外 ドメイン駆動設計で定義されたドメインモデル  実生活の関係性によって双方向の関係になることがある。  本当に必要かどうかを確認して、それでも必要な場合は それを維持する。 AV1020 双方向の依存を避ける
  17. 17.  振る舞いだけを持つ(静的な)クラス がある場合、それが 適用されるデータの近くにロジックを移動する。 例外  データ転送オブジェクト(Data Transfer Objects)  メソッドのパラメータをラップするクラス AV1025 クラスは状態と振る舞いを持つべきである
  18. 18.  プロパティは、他のプロパティに対してステートレスでな くてはならない。 プロパティの後でDataMemberをセットした  DataSource 場合とその逆で差があってはいけない。 AV1100 プロパティはあらゆる順番でセットできるようにする
  19. 19.  1つの型に2つの相反するコンセプトを持っている ドメインモデルでよく見られる AV1110 相互排他なプロパティを使用しない
  20. 20.  nullではなく、空のコレクションや空文字列を返すようにする AV1135 文字列やコレクションのプロパティ、メソッド、引数はnullであってはなら ない
  21. 21.  Exception、SystemExceptionなどでキャッチしない トップレベルのコードでは、きちんとキャッチしてログを はいて、終了する。 AV1210 汎用的な例外キャッチでエラーを飲み込まない
  22. 22.  イベントのサブスクライバが存在しない場合nullになるた め、呼び出す前にデリゲートリストであるイベント変数が nullでないことを確認する event EventHandler<NotifyEventArgs> Notify; void RaiseNotifyEvent(NotifyEventArgs args) { EventHandler<NotifyEventArgs> handlers = Notify; if (handlers != null) { handlers(this, args); } } AV1220 常にイベントハンドラのnullをチェックする
  23. 23.  イベントハンドラーのsender引数は、イベントソースを識 別するために使用される 通常はthisを渡せばよい イベントデータがない場合は、EventArgs.Emptyを渡す 例外 静的イベントでは、sender引数はnullでなくてはなら ない。 AV1235 イベントを発生させる時sender 引数としてnullを渡すべきではない
  24. 24.  以下のコードスニペットを考えてみよう 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式を戻り値として返す前に評価する
  25. 25.  7個より多いステートメントを持つメソッドは、多くのこ とをし過ぎているか、多くの責任を持ちすぎている。 コードが何をしているかを理解するために人が正確にス テートメントを分析する必要があります。 内容を説明した名前を持つ、複数の小さく、フォーカスさ れたメソッドに分割して、それでも高いレベルでアルゴリ ズムがまだ明確であることを確認する。 AV1500 メソッドは7ステートメントを超えるべきではない
  26. 26.  最初はスコープを可能な限り狭める。 その後慎重になにをpublicメンバーや型として公開するか を決める。 AV1501 デフォルトでは、すべてのメンバーをprivateに、型をinternalにする
  27. 27.  記号定数以外に数値、文字列のどちらにもリテラル値を使用してはいけない。 例えば: 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 “マジック” ナンバーを使ってはいけない
  28. 28.  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を使用する
  29. 29.  通常はbool型の式でtrue かfalseかを比較するためことはよ くないスタイルである。例えば: while (condition == false) // 間違えた、よくないスタイル while (condition != true) // これも誤り while (((condition == true) == true) == true) // どこまでいくの? while (condition) // OK AV1525 true やfalse を明示的に比較しない
  30. 30.  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ブロックを 追加する
  31. 31.  以下の例について考えてみよう if (member.HidesBaseClassMember && (member.NodeType != NodeType.InstanceInitializer)) { // なにかをする } この表現を理解するためには、詳細とすべての結果で、な にをしているのかを分析する必要がある。明らかに、上に コメントを追加することができるが、それよりも明確な名 前のメソッド名でこの複雑な表現を起きえる方がよいだろ う: if (NonConstructorMemberUsesNewKeyword(member)) { // なにかをする } private bool NonConstructorMemberUsesNewKeyword(Member member) { return (member.HidesBaseClassMember && (member.NodeType != NodeType.InstanceInitializer) } AV1547 メソッドやプロパティの複雑な表現をカプセル化する
  32. 32.  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 オプショナル引数は、オーバーロードを置き換えるためにだけ使用 する
  33. 33.  C# 4.0の名前付き引数は、大量のオプショナルパラメータ を提供するCOMコンポーネントの呼び出しを簡単にするた めに導入された。 メソッド呼び出しの可読性を改善するために名前付き引数 が必要なら、そのメソッドはおそらく多くのことをやり過 ぎているか、リファクタリングすべきである。 名前付き引数で可読性が改善する唯一の例外は、有効なオ ブジェクトを生み出すコンストラクターで以下のように呼 ばれたときだ: Person person = new Person ( firstName: "John", lastName: "Smith", dateOfBirth: new DateTime(1970, 1, 1) ); AV1555 名前付き引数の使用を避ける
  34. 34.  メソッドが3つより多いパラメータを必要とする場合、 Specificationデザインパターンで説明されているように、 複数の引数を渡すための構造体かクラスを使用する。一般 的にパラメータ数が少ないほうがメソッドを理解しやすい。 さらに、多くのパラメータが必要なメソッドのユニットテ ストには多くのシナリオが必要になる。 AV1561 3つより多いパラメータを受け取るメソッドやコンストラク ターを許可しない
  35. 35.  これらはコードを理解しづらくして、バグを引き起こすこ とがある。代わりに複合オブジェクトを返すようにする。 AV1562 ref やout パラメータを使用しない
  36. 36.  オブジェクトからインターフェイスの参照を取得するため にasを使っている場合、その操作がnullを返さないかを常 に確認する。 オブジェクトがインターフェイスを実装していないときに これを怠ると、ずっと後の段階でNullReferenceException が発生することがある。 AV1570 常に as 操作の結果をチェックする
  37. 37.  コメントアウトされたコードをチェックインしない やるべき作業を管理できる作業アイテムをトラックできる システムを使用する コメントアウトされたコードをみつけたときになにをする べきかを誰もわからない テストのために一時的に無効化している?サンプルをコ ピーした?そんなものは削除するべきだ。 AV1575 コードをコメントアウトしない
  38. 38.  英語を使用する場合、すべての型メンバー、パラメータ、変数 はアメリカ英語の単語を使用するべきである。 簡単で読みやすく、文法として正しい名前を選択する。例えば、 HorizontalAlignmentはAlignmentHorizontalよりも読みやすい 短さよりも読みやすさを選ぶ。CanScrollHorizontallyというプロ パティ名はScrollableX よりも優れている(X軸はあいまいな参照 である) プログラム言語で広く使われているキーワードとの衝突を避け る 例外 ほとんどのプロジェクトでは、ドメインや企業に固有の単 語やフレーズを使用する。Visual Studioの静的コード分析は、す べてのコードにスペルチェックを実行するため、カスタムコー ド分析辞書に用語を追加する必要がある。 AV1701 アメリカ英語を使用する
  39. 39. 言語要素 ケース 例クラス、構造体 Pascal AppDomainインターフェイス Pascal IBusinessService列挙型 Pascal ErrorLevel列挙値 Pascal FatalErrorイベント Pascal ClickPrivateフィールド Camel listItemProtectedフィールド Pascal MainPanelConstフィールド Pascal MaximumItemsConst変数 Camel maximumItemsRead-only静的フィールド Pascal RedValue変数 Camel listOfValuesメソッド Pascal ToString名前空間 Pascal System.Drawingパラメータ Camel typeName型パラメータ Pascal TViewプロパティ Pascal BackColor AV1702 言語要素に適したケースを使用する
  40. 40.  例えば、静的フィールドかどうかを区別するためにg_ や s_ を使用してはいけない 一般的にローカル変数かメンバー変数かの区別がつかない 場合、大きすぎることが多い 正しくない識別子名には次のようなものがある: _currentUser, mUserName, m_loginTime AV1705 フィールドにプレフィックスを使用しない
  41. 41. class Employee{ // 誤り! static GetEmployee() {} DeleteEmployee() {} // 正しい static Get() {...} Delete() {...} // これも正しい AddNewJob() {...} RegisterForMeeting() {...}} AV1710 クラスや列挙型のメンバーは、名前を繰り返えさない
  42. 42.  以下のステートメントは、技術的には正しいが混乱する可 能性が非常に高いbool b001 = (lo == l0) ? (I1 == 11) : (lOl != 101); AV1712 短い名前や他の名前と間違えられることがある名前は避ける
  43. 43.  例えば、Objectの代わりにobject、Stringの代わりにstring、 Int32の代わりにint これらのエイリアスはプリミティブ型としてC#言語の一級 市民として提供されているため、これらを使用するべきで ある 例外 これらの型の静的メンバーを参照するときは、完全な CLS名を使用する。例えば、int.Parse()の代わりに Int32.Parse() AV2201 System名前空間の型ではなく、C#の型エイリアスを使用する
  44. 44.  開発環境で、C#コンパイラの警告レベル 4で構成し、警告 をエラーとして扱うオプションを有効にする これはコンパイラに可能な限り最高のコード品質を強要す ることができる。 AV2210 最も高い警告レベルでビルドする
  45. 45.  dynamicキーワードは、動的言語で作業するために導入さ れた。コンパイラがいくつかの複雑なリフレクションコー ドを生成する必要があるため、これを使うことで深刻なパ フォーマンスのボトルネックになる可能性がある。 これは、(Activatorを使って)動的に生成されたインスタン スのメソッドやメンバーを呼び出すときだけ、 Type.GetProperty() 、Type.GetMethod()、COM互換型とし て操作する代わりに使用する AV2230 dynamicキーワードは動的オブジェクトを受け取るときだ け使用する
  46. 46. AV2301コメントとドキュメントをアメリカ英語で記述する
  47. 47.  コメントには「どのように(how)」ではなく、コードブ ロックの「なぜ(Why)」と「なに(What)」にフォーカスす る。ステートメントを言葉で説明するのを避け、なぜ (Why)そのソリューションやアルゴリズムを選択して、な に(What)を達成しようとしたのかを読み手が理解すること を助けよ。明確なソリューションで問題が発生したなどの 理由で代替手段を選んだのであれば、そのことについて触 れること。 AV2316 複雑なアルゴリズムや決定を説明するコメントのみを記述 する
  48. 48.  1行を130文字以内に抑える 4文字の空白インデントを使用して、タブを使用しない ifと式の間のようにキーワード間に空白をひとつ入れるが、 if (condition == null) のようにその前後には空白を追加し ない +、-、==など、演算子の周りに空白を追加する 言語的に必要なかったとしても、if、 else、 do、 while、 for、 foreachなどに開始と終了の括弧を置いて、常にキー ワードを成功させる。 開始と終了の括弧は常に新しい行に置く AV2400 一般的なレイアウトを使用する
  49. 49.  オブジェクト初期化子と各プロパティの初期化は、以下の ようにインデントせず、新しい行に書く: var dto = new ConsumerDto() { Id = 123, Name = “Microsoft”, PartnerShip = PartnerShip.Gold, } ブロックを持つラムダ式は、インデントせず、以下のよう に書く: methodThatTakesAnAction.Do(x => { // なにかする } AV2400 一般的なレイアウトを使用する
  50. 50.  クエリ式は、以下のように全体を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 一般的なレイアウトを使用する
  51. 51.  共通の並び順を維持することで、他のチームメンバーが簡単に コードで目的のものを見つけることができる。一般的にソース ファイルは、本を読むように上から下に読むことができるべき である。これは読者がコードファイルで上下に行き来しなけれ ばいけない状況を防ぐ。 privateフィールドと(領域の)定数 public定数 public readonly static フィールド ファクトリメソッド コンストラクターとファイナライザー イベント publicプロパティ 呼び出す順で、その他のメソッドとprivateプロパティ AV2406 メンバーを適切に定義された並び順にする
  52. 52.  Regionは便利なときもあるが、クラスの主な目的を隠すこ ともできてしまう。従って#regionは、以下の目的でのみ使 用する: privateフィールドと定数(できればprivate定義region) ネストされたクラス インターフェイスの実装(インターフェイスがそのクラス の主な目的でない場合のみ) AV2407 #regionを控える
  53. 53. 全部を採用する必要はありません。プロジェクトにあった選択を。

×