VB.NET コーディング規約

 [Home]


目的

この文書は、VB.NET 新人プログラマが、コーディングにおいて留意すべき事項にまとめたものである。


プロジェクト

このルールはプロジェクトごとにそのプロジェクトの性格、メンバー構成、規模、難易度などを考慮し、カスタマイズして使用するものとする。


命名規約

原則

クラスや変数等の命名については、原則、MSDN のサンプルコードを参考にすること。


個別規約

  1. クラス、モジュール、メソッド、プロパティ、名前空間などは英単語を基本とし大文字で始まるものとする。複数単語からなる場合は、単語の先頭は大文字、それ以外は小文字とする。_ や数字は使用しない。(理由:習慣による)
    ※ スペルが間違っているとみっともないので自信がないものは確認すること。
  2. 変数名は基本的に小文字で始まるものとする。複数単語からなる変数名の場合は、2つめ以降の単語の先頭は大文字にする。(理由:習慣による)
  3. 名前はその変数の使用目的を考慮し、わかりやすい名前を付けること。(理由: わかりやすさのため)
  4. 名前に英単語と日本語を混在したり、日本語のローマ字は使わないこと。(理由: オフショア開発にそのコードを流用した場合、海外のプログラマが意味を理解できない)
  5. 1文字または2文字など短い変数名を使用する場合は、下記の原則に従うこと。短い変数名はメソッド内のみで使用すること。(理由:習慣による)
  6. 日本語 (漢字、ひらがな等) のクラス名や変数名は原則使用しないこと。(理由: 海外版のソフトで文字化けの可能性、オフショア開発で海外プログラマが意味を理解できない)
  7. すべて大文字の名前は定数のみ使用できるものとする。これには Enum のメンバーを含む。(理由:習慣による)
  8. すべて小文字の名前はメソッド(プロパティを含む)内のみ使用できる。(理由:習慣による)
  9. キーワードと同じ名前の変数は使用しないこと。(理由:バグの原因になるため)
    ※ キーワードによっては変数として使ってもコンパイルエラーにならないものがある。

(注意) Visual Basic は過去の互換性ため大文字と小文字を区別しない。例えば If, if, IF のどれもコンパイルエラーにはならない。


コーディングスタイル

原則

コーディングスタイルについては、原則、MSDN のサンプルコードを参考にすること。

また、Visual Studio のデフォルトのフォーマッタ機能によるスタイルを変更しないこと。


個別規約

  1. 機能ごとに #Region を使用して Visual Studio で折り畳み表示ができるようにすること。(理由:見やすさ、開発の効率性)
  2. 基本的に #If を使用しないこと。(理由:削除を忘れた時の意図しないバグの可能性)
    デバッグ中に一時的に使用する場合は、デバッグ完了時に削除すること。
  3. 100行を超えるような長いメソッドは作らないこと。そのような場合は、いくつかのメソッドに分ける。(理由:見やすさ、バグ発生時の検出のしやすさ)
  4. 入れ子は最大でも3段階(推奨2段階まで)とする。(理由:見やすさのため)
  5. ブロック内のコードは最大でも50行程度とする。(理由:見やすさのため)
  6. メソッドの引数には、必ず ByVal (場合によっては ByRef) を付けること。(理由:あいまいさの除去)
  7. クラスやメソッドには、必ず Public や Private などを付けること。(理由:あいまいさの除去)
  8. マジックナンバーは原則使用しないこと。代わりに定数や Enum を使用する。
    [マジックナンバーの例] i = 100 などと書いたとき、この 100 が何を意味するのが分からない。ただし、初期化のための、i = 0 や s = "" は例外とする。
  9. 例外は最上位のクラスでキャッチすること。(理由:例外処理の統一性)
  10. 特別な場合を除き、条件判定で And の代わりに AndAlso、Or の代わりに OrElse を使用すること。(理由:副作用の防止、高速化)
  11. Dim はメソッド内のみで使用する。(理由:あいまいさの除去)
  12. 独自の Partial クラスは使用しないこと。(理由:見やすさのため)
  13. 独自の拡張メソッドを使用するときは、必ずコメントを入れて拡張メソッドであることを明確にすること。(理由:見やすさのため)
  14. 独自例外は原則使用しないこと。使用する場合は、必ず例外オブジェクトを定義すること。(理由:保守の容易性)

コメント

  1. クラス、モジュール、メソッド、プロパティ、クラスの変数にはコメントを入れて説明すること。これらのコメントは後でヘルプファイルを自動生成するため、''' で始める XML コメントとする。
  2. summery コメントには、そのクラス等の機能概要を記述すること。
  3. メソッドの引数 (param コメント) には、その引数の機能や意味を記述すること。ただし、標準のイベントハンドラなどで引数の意味が既知の場合は省略してもよい。
  4. remarks コメントには、機能詳細や備考を記述する。コードが短いメソッドやプロパティの場合は省略してよいが、原則、記述すること。
  5. メソッドやプロパティ内部にも、わかりやすさのために機能単位にコメントを入れること。
  6. 既存のコードを修正したとき、変更が必要な他のコメントも同時に変更すること(理由:変更箇所以外のコメントもたいてい変更が出るため)。同時に、意味がなくなったコメントは削除すること。
    ※ 通常、バージョン管理システムにより古いソースを取得できる。
  7. コードの意味と関係ないコメントは原則不要とする(プロジェクトの方針に依存)。一時的なものはリリースまでに必ず削除する。
    (例) TODO: .... や 何年何月 誰々さん追加など。
  8. 不要となった行のコメントアウトはリリースまでに必ず削除する。
  9. 変更履歴などのコメントはファイルの先頭にまとめる。

リソース

  1. アプリケーションで共通に使用するメッセージ、画像などはリソースに格納する。同様にアプリケーションの設定値は設定ファイルに格納する。
  2. 環境変数はアプリケーション共通の場合を除いて、使用禁止とする。
  3. アプリケーションの諸元やバージョン番号は、プロジェクトの基本方針に基づいてプロジェクトのプロパティに書く。

禁止事項

  1. ネットで検索したサンプルプログラムのコードをむやみにコピーして使わないこと。(理由:信頼性の欠如)
  2. 古いコレクションクラスを使用しないこと(例:ArrayList クラス)。代わりに Generic コレクションクラスを使用する。(理由:要素の型があいまいになる、古いコードの除去)
  3. デバッグやテストのためのコードはテスト完了後そのままにしないこと。(理由:保守性の向上)

制限事項

  1. GoTo 文は深い入れ子から脱出するときのみ使用できる。(理由:コードの見易さ)
  2. With 文は入れ子にしてはならない。(理由:コードの見易さ、あいまいさの除去)
  3. クラシック Visual Basic 互換関数は簡単な代替手段がある場合は使用しない。(理由:古いコードの除去、あいまいさの除去)
    [例] Asc(c) でなく Convert.ToInt32(c) を使用する。
  4. ReDim 文は原則使用しない。代わりに List(Of ..) を使用する。(理由:古いコードの除去)

推奨事項

  1. 変数を宣言するときは、型の指定を行う。(無意味でない場合を除き、同時に初期化するほうがよい)
  2. ローカル変数の宣言は原則メソッドの先頭で行う。