クラス名の命名規則

クラス名は、パスカルーケースを使用して名詞・名詞句または形容詞句で命名します。
 
クラス名にプレフィックス(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
 
出典
 

単語連結法 (of language)とは

単語連結法とは、変数を「主要部-修飾部-クラス」の形式で表現する記法です。
 
たとえば「CUSTOMER-OFFICES-ID」という変数名は「顧客の事業所のID」という意味になり、主要部に変数名で表したい実体(CUSTOMER)、修飾部に補助的な内容(OFFICES)、クラスは前述したハンガリアン記法のようにデータ型(ID)を設定します。
 
主観では汎用機、COBOLでよくつかわれる表記だと思います。
 
このサイトでは、もちろん単語連結法の変数名も作成できます。
 
 
例:サフィックスに「-ID」を指定し、文節区切り文字に「-」を指定
 
 
「顧客 事業所(こきゃく じぎょうしょ)」⇒「CUSTOMER-OFFICES-ID」
 
※「漢字・ひらがな・カタカナ ⇒ 英語」にて変換。
 

ハンガリアン記法(hungarian notation)とは

ハンガリアン記法とは、変数の先頭や末尾に特別な識別子を付けて、他の人がその変数を見たときにデータ型や使用方法・スコープなどを分かりやすくするための記法です。
 
C言語のポインタを「p」または「lp」から始める、文字列を「s」から始めるなどが有名ですが、私はこれほどプログラマに嫌われている記法を見たことがありません。
 
理由はシンプルに「型が変わった場合に変数名を全部直さなきゃならないから」につきると思います。
 
今でこそVisual Studioのリファクタ機能で一括置換が可能ですが、当時は「変数名を変える」⇒「ビルド」⇒「エラーになったところを全部直す」という手順を踏まなければならず、コアとなる変数名が変わったりしたものなら居室のあちこちから阿鼻叫喚が聞こえることも珍しくありませんでした。
 
そんな悪名高いハンガリアン記法ですが、設計時点では有用です。たとえば「これはテキストボックスだよ」を表現するときには「txt」を先頭に付ける、ボタンの場合は「btn」を付けるなどのルールを決めておけば、プログラマが迷うことはありません。
 
このサイトでは、プレフィックスやサフィックスに識別子を指定すると、ハンガリアン記法の変数名を簡単に作れます。
 
 
例:プレフィックスに「txt」を指定した場合
 
 
「電話番号(でんわ ばんごう)」⇒「txtDenwaBango」
 
 
例:サフィックスに「Text」を指定した場合
 
 
「電話番号(でんわ ばんごう)」⇒「DenwaBangoText」
 

スネークケース(snake case)とは

スネークケースとは、変数名を構成する単語をアンダースコア(_)で連結していく形式です。
 
私がC言語を習い始めたころは、スネークケースで表記すのが一般的でした。
 
たとえば「アップルパイ」を英語で表記すると「apple pie」になりますが、スネークケースでは「apple_pie」と表記できますので、英語表記の間隔を変えることなく変数名を命名できます。
 
このサイトでは、文節区切り文字で「_」を指定すると、スネークケースの変数名を簡単に作れます。
 
 
例:「アップルパイ(あっぷる ぱい)」⇒「apple_pie」
 
※「漢字・ひらがな・カタカナ ⇒ 英語」にて変換。
 

パスカルケース(pascal case)とは

パスカルケースとは、変数の先頭を大文字の単語から始め、文節ごとに大文字で始めた単語を連結していく形式です。
 
C#ではプロパティ名やメソッド名をパスカルケースで表記するのが一般的です。
 
このサイトでは、変換方法で「大文字始まり文節ごと大文字」を指定すると、パスカルケースの変数名を簡単に作れます。
 
 
例:「電話番号(でんわ ばんごう)」⇒「DenwaBango」
 
パスカルケースはアッパーキャメルケースとも呼ばれます。
 

キャメルケース(camel case)とは

キャメルケースとは、変数の先頭を小文字の単語から始め、文節ごとに大文字で始めた単語を連結していく形式です。
 
C#ではローカル変数やフィールド名をキャメルケースで表記するのが一般的です。
 
このサイトでは、変換方法で「小文字始まり文節ごと大文字」を指定すると、キャメルケースの変数名を簡単に作れます。
 
 
例:「電話番号(でんわ ばんごう)」⇒「denwaBango」
 

便利な使い方 その3

文節区切り文字にスペースを指定すると、名前・住所をローマ字に変換するときに便利です。
 
 
例:「北川景子(きたがわ けいこ)」⇒「Kitagawa Keiko」
g h T
 2,337 Total Views