C# クラス直下に書く “メンバー” 一覧

C# を学び始めると、「クラスの中に書くいろいろな“メンバー”が何を意味するのか」で混乱しがちです。

フィールド、プロパティ、メソッド……名前は聞くけれど、何がどう違い、いつ使い分けるのか を体系的に知る機会は意外と少ないもの。本資料は次の目的でまとめました。

  1. 初心者が最低限おさえるべき分類とキーワードを一望できるようにする
  2. “どんなときに使うか” と “命名規約” を同時に示し、実践で迷わないようにする
  3. 講義やチーム開発のコードレビューで共通言語として活用できるようにする

授業中にさっと参照できる「携帯版ポケットガイド」をイメージし、冗長な説明は削っています。

疑問にぶつかったらまずはこの表を開き、「自分が書こうとしているものはどれに該当するか」を確かめてみてください。それだけで設計ミスや命名ブレがかなり減るはずです。

C# クラス直下に書く “メンバー” 一覧 ― 用途・キーワード・命名規約を一気に整理

種類キーワード例どんなとき使う？インスタンス単位 or クラス全体典型的な命名
インスタンス フィールドprivate int _score;オブジェクト固有の内部状態インスタンス_camelCase
静的フィールドprivate static int s_count;すべてのオブジェクトで共有したい値クラス全体s_ + camelCase
読み取り専用フィールドprivate readonly Guid _id;生成時に決めて以後変更させない値インスタンス_camelCase
静的読み取り専用private static readonly DateTime s_start;実行時に決めて固定したい共有値クラス全体s_
定数フィールドpublic const string AppName = “MyApp";コンパイル時に確定する定数クラス全体PascalCase
スレッド静的フィールド[ThreadStatic] private static int t_local;スレッドごとに独立した値スレッド単位t_
プロパティpublic int Count { get; private set; }値の公開をカプセル化したいインスタンス / クラスPascalCase
イベントpublic event EventHandler Completed;外部に通知したいインスタンス / クラスPascalCase
メソッドpublic void Run() / public static int Parse()振る舞いを実装インスタンス / クラスPascalCase
ネスト型private class Node { }補助的な型を内側に隠す―PascalCase

結論 ― “s_ + camelCase” は Microsoft 公式ガイドラインの必須事項ではなく、

.NET Runtime チームや Microsoft Docs 執筆チームが採用している現行デファクト規約**です。

どこに書かれているか

出典内容発行年
C# identifier naming rules and conventions（docs 副読本）“Static fields start with s_. This convention isn’t the default Visual Studio behavior, nor part of the Framework Design Guidelines, but is configurable in EditorConfig.”  2023–
Framework Design Guidelines (Names of Fields)“❌ DO NOT use a prefix for field names (for example ‘s_’).” ※対象は public / protected static フィールド, private/internal は対象外  2008（改訂は 2023-10 ページ更新）

整理すると

  • 私的／internal な static フィールド → Docs & .NET Runtime コードでは s_ プレフィックスを付ける例が主流。
  • public / protected static フィールド → Framework Design Guidelines ではプレフィックス禁止（PascalCase 推奨）。
  • Visual Studio のデフォルトテンプレートも s_ は付けません。付けたい場合は .editorconfig でコードスタイル規則 (dotnet_naming_rule) を追加して IDE に指示します。

実務でどう決める？

  1. チーム標準が最優先既存コードやレビュー方針に合わせる。混在は避ける。
  2. 非公開 static を「一目で区別」したいなら s_ が便利IDE の IntelliSense でも目立つため、大規模コードベース (.NET Runtime, Roslyn など) で採用例が多い。
  3. 公開 API を作るライブラリならプレフィックス無し＋PascalCasePublic surface は Framework Design Guidelines を尊重し、MaxCount のように書く方が一般的。

.editorconfig で強制する例（抜粋）

# static フィールドは s_camelCase
dotnet_naming_rule.static_fields_should_have_prefix.severity = warning
dotnet_naming_rule.static_fields_should_have_prefix.symbols  = static_fields
dotnet_naming_rule.static_fields_should_have_prefix.style    = s_prefix_style

dotnet_naming_symbols.static_fields.applicable_kinds = field
dotnet_naming_symbols.static_fields.required_modifiers = static

dotnet_naming_style.s_prefix_style.required_prefix = s_
dotnet_naming_style.s_prefix_style.capitalization  = camel_case

このように設定すれば IDE が違反を警告してくれるため、チーム内で規約を徹底しやすくなります。

まとめ

  • “s_ + camelCase” は Microsoft 製ランタイム／Docs が採用するモダンな私的 static フィールド命名。
  • 公式必須ではなく「選択可能な慣習」。
  • 公開 API 用コードでは旧来の Framework Design Guidelines（プレフィックス無し）の方が今も推奨。
項目なぜ避ける？ガイドライン出典
フィールド名へのプレフィックス (m_, s_, g_ など)公開 API での可読性を下げ、将来の自動生成ツールでも扱いにくくなる。特に public / protected なフィールドでは禁止。“DO NOT use a prefix for field names.” 
ハンガリアン記法 (strName, nCount など)型推論や IDE 支援が発達した現在では冗長。読みやすさより暗号化につながる。“DO NOT use Hungarian notation.” 
アンダースコア・ハイフンなどの記号を多用CLS 準拠や他言語バインディングで問題を起こしやすい。“DO NOT use underscores, hyphens, or any other non-alphanumeric characters.” 
連続アンダースコア __コンパイラ生成識別子と衝突する恐れがあるため予約済み。“Identifiers shouldn’t contain two consecutive underscore (__) characters.” 
略語・省略形の乱用 (btn, calc, cfgMgr など)英語圏以外の開発者が意味を推測しづらい。長期保守で負債になりやすい。“DO NOT use abbreviations or contractions as part of identifier names.” 
広く知られていない頭字語を全大文字で書く (XmlHTTPRequest)“読める単語” に見えず視認性が落ちる。2 文字頭字語のみ全大文字が推奨。同上（一般命名規約） 
キーワードと衝突する識別子 (class, switch など)@class のようなエスケープが必要になり、利用側の負担が増える。“AVOID using identifiers that conflict with keywords of widely used programming languages.” 
旧版 API を Ex, Plus, New で区別 (OpenEx, StartNew)意味が曖昧で将来さらにバージョンが増えたとき破綻しやすい。数値サフィックスなどを推奨。“DO NOT use the ‘Ex’ (or similar) suffix for an identifier to distinguish it from an earlier version …” 

実務 Tip

  • これらは 公開 API を作るときほど厳密に守られます。内部実装だけのコードではチーム合意を優先して OK。
  • Visual Studio / Rider なら EditorConfig に dotnet_naming_rule を追加し、上記 NG パターンを 警告 や エラー に昇格させると統一がラクになります。

押さえておきたい 4 つの鉄則

  1. 状態はフィールド、公開はプロパティフィールドをむき出し (public) にせず、外部にはプロパティ経由でアクセスさせる。
  2. static が付けば「共有」インスタンスを何個作っても 1 つしか存在しない。
  3. readonly / const で「変更禁止」実行時に決定→ readonly、コンパイル時に決定→ const。
  4. 命名は “読めば役割がわかる” を最優先名前にスコープや寿命がにじむと、読み手に優しいコードになる。

使い方のヒント

  • コードレビューで「これは静的フィールドにすべきでは？」といった議論をするとき、この表を指差しながら確認すると話が早いです。
  • 自分用チェックリストとして印刷し、命名や修飾子を決める前に 30 秒だけ眺めるクセをつけると、初歩的な設計ミスを防げます。
訪問数 5 回, 今日の訪問数 1回

C#,命名規則

Posted by hidepon