カテゴリー : .NETの命名規則

 

クラス名の命名規則

クラス名は、パスカルーケースを使用して名詞・名詞句または形容詞句で命名します。
 
クラス名にプレフィックス(Cなど)を付けることは禁止です。
 
派生クラスの場合、クラス名の末尾に基本クラスの名前を付けるように考慮します。
 
 
例:「Stream」クラスを派生した「MemoryStream」など。
 
出典
 

アセンブリとDLLの命名規則

名前空間が論理的な構成なのに対し、アセンブリやDLLは物理的な構成になります。アセンブリやDLLはプロジェクト単位に作成されることが多く、そのため名前空間が複数のアセンブリにまたがることも珍しくありません。
 
アセンブリ名の一般的な形式は以下になります。
 
 
会社名.コンポーネント名.(dll|exe)
 
ここで名前空間の一般形式を思い出してください。
 
 
会社名.(製品名|技術名)[.特徴][.サブ名前空間]
 
私はよく「特徴」をプロジェクトごとに命名し、下線の部分をアセンブリ名(「会社名.コンポーネント名」の部分)とするルールを採用しています。
 
出典
 

名前空間の命名規則

.NETでプロジェクトを作成したら、一番最初に名前空間を命名し、サブ名前空間のルールを決めます。
 
もちろんルールがなくても開発はできますが、プロジェクトが大きくなった場合に使用したい機能が見つからない ⇒ 仕方がないので自作する ⇒ 同じような機能のクラスがあちこちに点在 ⇒ ますますカオスに。。といった負のスパイラルに陥ってしまいます。
 
名前空間の一般的な形式は以下になります。
 
 
会社名.(製品名|技術名)[.特徴][.サブ名前空間]
 
※「特徴」と「サブ名前空間」はプロジェクトごとに定義します(無くてもかまいません)。
 
会社内の組織(事業所など)は変更されることが多いので避けたほうが無難です。
 
ここでいつも問題になるのが「サブ名前空間」ですね。どんな場合にもあてはまるわけではありませんが、私は以下のような構成をベースに考えています。
 
名前空間のベース
 
エンティティ
 
ユーティリティ
 
業務名
 
 
画面
 
 
業務ロジック
 
 
コントローラー(画面と業務ロジックの橋渡し)
 
 
業務ごとのユーティリティ
 
「エンティティ」と「ユーティリティ」は業務をまたいで使用するケースが多いので「業務名」と同列に、業務名にMVCモデルの各要素とユーティリティを内包し、業務の数分「業務名」が作成されるイメージです。
 
出典
 

.NETの命名規則ガイドライン

.NETで使用するアセンブリや名前空間、型やメンバーなどのクラスライブラリの構成要素を命名するには、パスカルケースを使用します。
 
パスカルケースを使用する場合でも、2文字の略称(IOやDBなど)は全て大文字で命名し、3文字以上の略称(XmlやHtmlなど)はパスカルケースで命名します。
 
メソッドのパラメーターやローカル変数を命名するには、キャメルケースを使用します。
 
キャメルケースの先頭が略称の場合、全て小文字で命名します(dbNameなど)。
 
※ここでの略称は「世間一般(またはプロジェクト内)で広く受け入れられている略称」を指します。個人で勝手に略称を作成するのは禁止です。
 
パスカルケースを使用するクラスライブラリの構成要素
 
クラス名
 
 
例:CustomerEntity
 
列挙型
 
 
例:ErrorLevel
 
列挙値
 
 
例:FatalError
 
イベント
 
 
例:ValueChanged
 
例外クラス
 
 
例:NullReferenceException
 
読み取り専用の静的フィールド
 
 
例:RedValue
 
Interface
 
 
例:IDisposable
 
メソッド
 
 
例:ToString
 
名前空間
 
 
例:System.Drawing
 
プロパティ
 
 
例:BackColor
 
出典
g h T
 1,201 Total Views