一般的な名前付け規則
Note
このコンテンツは、Pearson Education, Inc. の許可を得て、『Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition (フレームワーク設計ガイドライン: 再利用可能な .NET ライブラリの規約、表現形式、およびパターン、第 2 版)』から転載されています。 この版は 2008 年に出版され、その後、この本は第 3 版で全面的に改訂されました。 このページの情報の一部は古くなっている可能性があります。
このセクションでは、単語の選択に関連する一般的な名前付け規則、略語と頭字語の使用に関するガイドライン、言語固有の名前の使用を回避するための推奨事項について説明します。
単語の選択
✔️ 簡単に判読できる識別子名を選択します。
たとえば、HorizontalAlignment という名前のプロパティは、AlignmentHorizontal よりも英語として読みやすくなります。
✔️ 簡潔さよりも読みやすさを優先します。
CanScrollHorizontally というプロパティ名は、ScrollableX (X 軸へのあいまいな参照) よりも優れています。
❌ アンダースコア、ハイフン、英数字でないその他の文字はいずれも使用しないでください。
❌ ハンガリアン記法は使用しないでください。
❌ 広く使用されているプログラミング言語のキーワードと競合する識別子を使用することは避けてください。
共通言語仕様 (CLS) の規則 4 に従って、すべての準拠言語には、その言語のキーワードを識別子として使用する名前付き項目へのアクセスを許可する機構が提供されている必要があります。 たとえば、C# ではこの場合にエスケープ メカニズムとして @ 記号が使用されます。 ただし、エスケープ シーケンスを持つメソッドは、それのないメソッドよりもかなり使い方が難しいため、一般的なキーワードを避けることをお勧めします。
省略形と頭字語の使用
❌ 省略形または短縮形を識別子名の一部として使用しないでください。
たとえば、GetWin ではなく GetWindow を使用します。
❌ 広く受け入れられていない頭字語は使用しないでください。受け入れられている場合でも、必要な場合に限って使用します。
言語固有名の回避
✔️ 型名には言語固有のキーワードではなく、意味的に興味を持たせるような名前を使用します。
たとえば、GetLength は GetInt よりもわかりやすい名前です。
✔️ 識別子がその型以上のセマンティックな意味を持たないまれなケースでは、言語固有の名前ではなく、汎用的な CLR 型名を使用します。
たとえば、Int64 に変換するメソッドは、ToLong ではなく ToInt64 という名前にする必要があります (Int64 は C# 固有のエイリアス long の CLR 名であるため)。 次の表は、CLR 型名を使用したいくつかの基本データ型を (C#、Visual Basic、C++ の対応する型名と共に) 示したものです。
| C# | Visual Basic | C++ | CLR |
|---|---|---|---|
| sbyte | SByte | char | SByte |
| byte | Byte | unsigned char | Byte |
| short | Short | short | Int16 |
| ushort | UInt16 | unsigned short | UInt16 |
| int | Integer | int | Int32 |
| uint | UInt32 | unsigned int | UInt32 |
| long | Long | __int64 | Int64 |
| ulong | UInt64 | unsigned __int64 | UInt64 |
| float | Single | float | Single |
| double | Double | double | Double |
| bool | Boolean | bool | Boolean |
| char | Char | wchar_t | Char |
| string | String | String | String |
| object | Object | Object | Object |
✔️ 識別子にセマンティックな意味がなく、パラメーターの型が重要でないまれなケースでは、型名を繰り返すのではなく、value や item などの一般的な名前を使用します。
既存の API の新しいバージョンの命名
✔️ 既存の API の新しいバージョンを作成するときに、古い API に似た名前を使用します。
これは、API 間の関係を強調するのに役立ちます。
✔️ 既存の API の新しいバージョンを示すには、プレフィックスではなくサフィックスを追加することをお勧めします。
これにより、ドキュメントを参照するときや、IntelliSense を使用するときに、検索がしやすくなります。 ほとんどのブラウザーと IntelliSense で識別子はアルファベット順に表示されるため、旧バージョンの API が新しい API の近くに配置されます。
✔️ サフィックスまたはプレフィックスを追加するのではなく、まったく新しい、それでいてわかりやすい識別子の使用を検討してください。
✔️ 既存の API の新しいバージョンを示すために数字のサフィックスを使用します (特に、既存の API 名が意味のある唯一の名前 (それが業界標準である場合など) であり、意味のあるサフィックスを追加 (または名前を変更) することが適切な選択肢でない場合)。
❌ 同じ API の以前のバージョンと区別するために、識別子に "Ex" (または同様の) サフィックスを使用しないでください。
✔️ 32 ビット整数ではなく 64 ビット整数 (長整数) で動作する API のバージョンを導入するときは、"64" というサフィックスを使用します。 このアプローチは、既存の 32 ビット API が存在する場合にのみ行う必要があります。64 ビット バージョンのみしかない新しい API に対しては行わないでください。
Portions © 2005, 2009 Microsoft Corporation. All rights reserved.
2008 年 10 月 22 日に Microsoft Windows Development シリーズの一部として、Addison-Wesley Professional によって発行された、Krzysztof Cwalina および Brad Abrams による「Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition」 (フレームワーク デザイン ガイドライン: 再利用可能な .NET ライブラリの規則、用法、パターン、第 2 版) から Pearson Education, Inc. の許可を得て再印刷されています。