C#命名規則を完全解説｜初心者でも迷わないクラス・メソッド・変数名の付け方と実例

はじめに

C#で読みやすく保守しやすいコードを書くうえで、命名規則はとても重要です。

クラス名、メソッド名、変数名、フィールド名などの付け方がバラバラだと、コードの意味を読み取るのに時間がかかります。逆に、C#命名規則に沿って名前を付ければ、初心者でもコードの役割を理解しやすくなり、チーム開発でも認識のズレを減らせます。

この記事では、C#命名規則の基本から、クラス・メソッド・変数・定数・フィールドの具体的な命名例、Visual StudioやEditorConfigを使った自動チェック方法まで、初心者にもわかりやすく解説します。

1. C#命名規則とは？初心者が最初に押さえるべき基本

1-1. 命名規則とは何か

命名規則とは、プログラム内で使う名前の付け方に関するルールです。

C#では、次のようなものに名前を付けます。

C#
public class CustomerService
{
    private readonly CustomerRepository _customerRepository;

    public Customer GetCustomerById(int customerId)
    {
        bool exists = customerId > 0;
        // 処理
    }
}

この例では、CustomerService、_customerRepository、GetCustomerById、customerId、exists などが命名の対象です。

命名規則は、単に見た目をそろえるためだけのものではありません。名前を見ただけで「何を表しているのか」「どのような役割なのか」が伝わるようにするためのルールです。

1-2. C#で命名規則が重要な理由

C#命名規則が重要な理由は、コードの読みやすさに直結するからです。

たとえば、次のような名前は意味がわかりにくいです。

C#
public class Data
{
    public void Do(int x)
    {
    }
}

一方で、次のように名前を付けると役割が明確になります。

C#
public class OrderService
{
    public void CancelOrder(int orderId)
    {
    }
}

OrderService は注文に関する処理を行うクラス、CancelOrder は注文をキャンセルするメソッド、orderId は注文IDを表す引数だとすぐにわかります。

プログラムは書く時間よりも読む時間のほうが長くなりがちです。そのため、C#では「自分が書きやすい名前」ではなく「他人や未来の自分が読みやすい名前」を付けることが大切です。

1-3. 命名規則とコンパイルエラーの違い

命名規則に違反しても、必ずコンパイルエラーになるわけではありません。

たとえば、次のコードはC#としては動作します。

C#
public class customer_service
{
    public void get_customer()
    {
    }
}

しかし、C#の一般的な命名規則から見ると、クラス名やメソッド名にスネークケースを使っているため、読みやすいC#コードとは言いにくいです。

一方、次のような名前は構文上の問題があるためエラーになります。

C#
int 1count = 10; // 数字から始まるためエラー
int class = 1;  // 予約語のためエラー

つまり、命名には「言語仕様として許されるか」と「規約として望ましいか」の2つの観点があります。

1-4. Microsoft公式の命名規則と現場ルールの関係

C#には、Microsoftが推奨する命名ガイドラインがあります。基本的には、公開されるクラス、メソッド、プロパティなどにはPascalCaseを使い、ローカル変数や引数にはcamelCaseを使うのが一般的です。

ただし、実際の現場では会社やプロジェクトごとのルールがある場合もあります。

たとえば、privateフィールドについては次のように複数の流派があります。

C#
private string _userName;
private string userName;

どちらを使うかは、プロジェクトの規約に合わせることが重要です。公式ルールを理解したうえで、現場のルールに従うのが実務では最も安全です。

1-5. 初心者が命名で迷いやすいポイント

初心者がC#命名規則で迷いやすいのは、主に次のような点です。

クラス名は名詞にするのか、メソッド名は動詞にするのか、変数名はどれくらい具体的にするのか、privateフィールドにアンダースコアを付けるのか、定数は大文字にするのか、といった部分です。

最初から完璧に覚える必要はありません。まずは、クラス・メソッド・プロパティはPascalCase、変数・引数はcamelCaseという基本を押さえるだけでも、かなりC#らしいコードになります。

2. C#命名規則の基本ルール一覧

2-1. PascalCaseとは

PascalCaseとは、単語の先頭をすべて大文字にする書き方です。

C#
CustomerService
GetUserName
OrderDetail
IsActive

C#では、主に次のような名前にPascalCaseを使います。

C#
public class CustomerService
{
    public string CustomerName { get; set; }

    public void RegisterCustomer()
    {
    }
}

クラス名、メソッド名、プロパティ名、イベント名、列挙型名などはPascalCaseにするのが基本です。

2-2. camelCaseとは

camelCaseとは、最初の単語だけ小文字で始め、2語目以降の先頭を大文字にする書き方です。

C#
customerName
orderId
isActive
totalPrice

C#では、主にローカル変数やメソッド引数にcamelCaseを使います。

C#
public void UpdateCustomerName(int customerId, string customerName)
{
    bool isValid = customerId > 0;
}

customerId、customerName、isValid はcamelCaseです。

2-3. アンダースコアの使い方

C#では、アンダースコアは主にprivateフィールドに使われることがあります。

C#
private readonly CustomerRepository _customerRepository;
private int _retryCount;

この書き方により、ローカル変数や引数とフィールドを区別しやすくなります。

C#
public class CustomerService
{
    private readonly CustomerRepository _customerRepository;

    public CustomerService(CustomerRepository customerRepository)
    {
        _customerRepository = customerRepository;
    }
}

ただし、アンダースコアを使うかどうかはプロジェクトによって異なります。チーム開発では、既存コードの書き方に合わせましょう。

2-4. 大文字・小文字の使い分け

C#は大文字と小文字を区別します。

C#
int count = 1;
int Count = 2;

この2つは別の変数として扱われます。

ただし、大文字小文字だけが違う名前を使うと非常に紛らわしくなります。

C#
int userId = 1;
int UserId = 2; // 紛らわしい

C#命名規則では、役割に応じてPascalCaseとcamelCaseを使い分けることが大切ですが、同じスコープ内で大文字小文字だけが違う名前を使うのは避けましょう。

2-5. 略語・省略形を使うときの注意点

略語は使いすぎると意味が伝わりにくくなります。

悪い例です。

C#
int cnt;
string usrNm;
DateTime regDt;

良い例です。

C#
int count;
string userName;
DateTime registeredAt;

ただし、Id、Url、Xml、Html など、一般的に広く使われる略語は問題ありません。

C#
int userId;
string imageUrl;
string htmlContent;

チーム内で意味が共有されていない略語は避け、できるだけ読み手に伝わる名前を使いましょう。

2-6. 読みやすい名前を付けるための共通原則

読みやすい名前を付けるためには、次の考え方が重要です。

名前は短すぎても長すぎても読みにくくなります。x や data のように抽象的すぎる名前は避け、何を表しているかがわかる名前にしましょう。

C#
// 悪い例
var data = GetData();

// 良い例
var customers = GetCustomers();

また、型名をそのまま変数名にするより、役割がわかる名前を付けるほうが親切です。

C#
// 悪い例
string str;

// 良い例
string customerName;

3. クラス・インターフェイス・名前空間の命名規則

3-1. クラス名の付け方

クラス名はPascalCaseで、名詞または名詞句にするのが基本です。

C#
public class Customer
{
}

public class OrderService
{
}

public class InvoiceCalculator
{
}

クラスは「もの」や「役割」を表すため、GetCustomer のような動詞から始まる名前は通常避けます。

悪い例です。

C#
public class GetCustomer
{
}

良い例です。

C#
public class CustomerRepository
{
}

3-2. インターフェイス名は「I」から始める

C#では、インターフェイス名の先頭に I を付けるのが一般的です。

C#
public interface IRepository
{
}

public interface ICustomerService
{
}

public interface ILogger
{
}

実装クラスは、インターフェイス名から I を除いた名前にすることが多いです。

C#
public interface ICustomerService
{
    Customer GetCustomer(int customerId);
}

public class CustomerService : ICustomerService
{
    public Customer GetCustomer(int customerId)
    {
        return new Customer();
    }
}

3-3. 名前空間の命名規則

名前空間はPascalCaseで、会社名、製品名、機能名などを階層的に表します。

C#
namespace MyCompany.SalesManagement.Customers
{
}

一般的な形式は次のようになります。

C#
namespace CompanyName.ProductName.FeatureName
{
}

名前空間は、クラスの所属や役割を整理するためのものです。意味のない名前や広すぎる名前は避けましょう。

C#
// 悪い例
namespace Common
{
}

// 良い例
namespace MyApp.Users.Services
{
}

3-4. 構造体の命名規則

構造体もクラスと同じくPascalCaseで命名します。

C#
public struct Point
{
    public int X { get; set; }
    public int Y { get; set; }
}

構造体は値を表す型として使われることが多いため、名詞や名詞句にします。

C#
public struct Money
{
    public decimal Amount { get; set; }
    public string Currency { get; set; }
}

3-5. 列挙型の命名規則

列挙型もPascalCaseを使います。

C#
public enum OrderStatus
{
    Pending,
    Shipped,
    Delivered,
    Canceled
}

列挙型名は単数形にすることが多いです。値もPascalCaseにします。

フラグとして複数の値を組み合わせる場合は、複数形にすることがあります。

C#
[Flags]
public enum FilePermissions
{
    None = 0,
    Read = 1,
    Write = 2,
    Execute = 4
}

3-6. 属性クラスの命名規則

属性クラスは、末尾に Attribute を付けます。

C#
public class RequiredAttribute : Attribute
{
}

public class CustomValidationAttribute : Attribute
{
}

使用するときは、Attribute を省略できます。

C#
[Required]
public string Name { get; set; }

クラス名としては RequiredAttribute、利用時は [Required] と書ける点を覚えておきましょう。

3-7. ジェネリック型パラメータの命名規則

ジェネリック型パラメータは、単純な場合は T を使います。

C#
public class Repository<T>
{
}

複数ある場合や意味を明確にしたい場合は、T から始まる名前にします。

C#
public interface IMapper<TSource, TDestination>
{
    TDestination Map(TSource source);
}

TKey、TValue、TEntity、TResult などはよく使われます。

4. メソッド・プロパティ・イベントの命名規則

4-1. メソッド名の付け方

メソッド名はPascalCaseで、動詞または動詞句にするのが基本です。

C#
public void SaveCustomer()
{
}

public Customer GetCustomerById(int customerId)
{
    return new Customer();
}

public decimal CalculateTotalPrice()
{
    return 0;
}

メソッドは処理を表すため、Save、Get、Create、Update、Delete、Calculate、Validate などの動詞から始めると意味が伝わりやすくなります。

4-2. プロパティ名の付け方

プロパティ名はPascalCaseで、名詞または形容詞句にします。

C#
public string CustomerName { get; set; }

public int Age { get; set; }

public bool IsActive { get; set; }

プロパティは値や状態を表すため、メソッドのような動詞から始める名前は避けるのが基本です。

C#
// 避けたい例
public string GetCustomerName { get; set; }

// 良い例
public string CustomerName { get; set; }

4-3. イベント名の付け方

イベント名もPascalCaseを使います。

C#
public event EventHandler CustomerCreated;
public event EventHandler OrderCanceled;

イベントは「何が起きたか」を表す名前にします。

C#
public event EventHandler Saved;
public event EventHandler Closed;

イベントハンドラは、On を付けたメソッド名にすることが多いです。

C#
protected virtual void OnCustomerCreated()
{
    CustomerCreated?.Invoke(this, EventArgs.Empty);
}

4-4. 非同期メソッドはAsyncを付けるべきか

C#では、非同期メソッドには末尾に Async を付けるのが一般的です。

C#
public async Task<Customer> GetCustomerAsync(int customerId)
{
    return await _repository.FindAsync(customerId);
}

Async を付けることで、そのメソッドが非同期処理であることが呼び出し側に伝わります。

C#
await customerService.GetCustomerAsync(1);

ただし、イベントハンドラなど一部のケースでは Async を付けないこともあります。基本的には、Task や Task<T> を返す非同期メソッドには Async を付けると覚えておくとよいでしょう。

4-5. boolを返すメソッド・プロパティの命名

bool型の名前は、trueまたはfalseの意味が自然に読めるようにします。

C#
public bool IsActive { get; set; }

public bool HasPermission { get; set; }

public bool CanDelete { get; set; }

public bool ShouldRetry { get; set; }

メソッドの場合も同様です。

C#
public bool IsValidEmail(string email)
{
    return email.Contains("@");
}

public bool CanAccess(User user)
{
    return true;
}

Is、Has、Can、Should を使うと、boolであることがわかりやすくなります。

4-6. 戻り値や処理内容が伝わるメソッド名の考え方

メソッド名は、処理内容と戻り値がイメージできる名前にしましょう。

悪い例です。

C#
public decimal Process(Order order)
{
    return 0;
}

Process だけでは、何を処理するのかわかりません。

良い例です。

C#
public decimal CalculateTotalPrice(Order order)
{
    return 0;
}

この名前なら、注文の合計金額を計算するメソッドだとわかります。

また、データを取得するだけなら Get、新しく作るなら Create、保存するなら Save、検証するなら Validate のように、動詞を使い分けると読みやすくなります。

5. 変数・定数・フィールド・引数の命名規則

5-1. ローカル変数の命名規則

ローカル変数はcamelCaseを使います。

C#
int customerCount = 10;
string userName = "Taro";
bool isActive = true;

変数名は、値の意味がわかる名前にします。

C#
// 悪い例
var d = DateTime.Now;

// 良い例
var currentDate = DateTime.Now;

短いスコープで明らかな場合を除き、1文字の変数名は避けましょう。

5-2. メソッド引数・パラメータの命名規則

メソッド引数もcamelCaseを使います。

C#
public void RegisterCustomer(string customerName, string emailAddress)
{
}

引数名は、呼び出し側から見ても意味が伝わる名前にします。

C#
// 悪い例
public void Send(string s, string t)
{
}

// 良い例
public void SendEmail(string subject, string body)
{
}

5-3. privateフィールドの命名規則

privateフィールドは、camelCaseまたは先頭にアンダースコアを付けたcamelCaseがよく使われます。

C#
private string customerName;

または、

C#
private string _customerName;

特に、コンストラクタで依存オブジェクトを受け取る場合、アンダースコア付きのprivate readonlyフィールドがよく使われます。

C#
public class OrderService
{
    private readonly IOrderRepository _orderRepository;

    public OrderService(IOrderRepository orderRepository)
    {
        _orderRepository = orderRepository;
    }
}

どちらが正解というより、プロジェクト内で統一することが大切です。

5-4. publicフィールドを避けるべき理由

C#では、publicフィールドよりもプロパティを使うのが一般的です。

避けたい例です。

C#
public class Customer
{
    public string Name;
}

良い例です。

C#
public class Customer
{
    public string Name { get; set; }
}

プロパティにしておくと、あとからバリデーションや読み取り専用化などを追加しやすくなります。

C#
public string Name { get; private set; }

外部に公開する値は、基本的にフィールドではなくプロパティにしましょう。

5-5. 定数 const の命名規則

C#の定数はPascalCaseで命名するのが一般的です。

C#
public const int MaxRetryCount = 3;
public const string DefaultUserName = "Guest";

他の言語では MAX_RETRY_COUNT のような大文字スネークケースを使うことがありますが、C#ではPascalCaseがよく使われます。

C#
// C#では一般的ではない
public const int MAX_RETRY_COUNT = 3;

// C#らしい
public const int MaxRetryCount = 3;

5-6. readonlyフィールドの命名規則

readonlyフィールドも、privateであればアンダースコア付きcamelCaseがよく使われます。

C#
private readonly ILogger _logger;
private readonly int _maxRetryCount;

public static readonly のように外部へ公開する場合はPascalCaseにします。

C#
public static readonly TimeSpan DefaultTimeout = TimeSpan.FromSeconds(30);

アクセス修飾子によって命名を使い分けると、C#らしいコードになります。

5-7. ループ変数・一時変数の命名で注意すること

ループ変数では、短い名前が許容されることがあります。

C#
for (int i = 0; i < items.Count; i++)
{
}

ただし、意味のある値なら具体的な名前を付けましょう。

C#
foreach (var customer in customers)
{
    Console.WriteLine(customer.Name);
}

一時変数でも、temp や data だけでは意味が伝わりにくい場合があります。

C#
// 悪い例
var temp = CalculateTotalPrice(order);

// 良い例
var totalPrice = CalculateTotalPrice(order);

6. 具体例でわかるC#命名規則の良い例・悪い例

6-1. クラス名の良い例・悪い例

悪い例です。

C#
public class data
{
}

public class DoOrder
{
}

public class Manager
{
}

良い例です。

C#
public class Customer
{
}

public class OrderService
{
}

public class PaymentManager
{
}

クラス名はPascalCaseにし、何を表すクラスなのかがわかる名前にしましょう。Manager のような広すぎる名前は、できれば具体化します。

6-2. メソッド名の良い例・悪い例

悪い例です。

C#
public void Do()
{
}

public void Process()
{
}

public void Data()
{
}

良い例です。

C#
public void CreateOrder()
{
}

public void SendEmail()
{
}

public void ValidateUserInput()
{
}

メソッド名は処理を表すため、動詞から始めると自然です。

6-3. 変数名の良い例・悪い例

悪い例です。

C#
int a;
string str;
var data;

良い例です。

C#
int retryCount;
string customerName;
var activeUsers;

変数名は、値の意味がわかる名前にします。

6-4. bool名の良い例・悪い例

悪い例です。

C#
bool check;
bool flag;
bool status;

良い例です。

C#
bool isChecked;
bool hasError;
bool canSubmit;
bool shouldRetry;

bool名は、trueのときにどういう状態なのかが読める名前にしましょう。

6-5. 略語を使った名前の良い例・悪い例

悪い例です。

C#
string usrNm;
int maxCnt;
DateTime updDt;

良い例です。

C#
string userName;
int maxCount;
DateTime updatedAt;

略語は、コードを書いた本人にはわかっても、他の人には伝わらないことがあります。基本的には省略しすぎないほうが安全です。

6-6. 初心者がやりがちなNG命名

初心者がやりがちなNG命名には、次のようなものがあります。

C#
public class Class1
{
    public void Method1()
    {
        int value1 = 10;
    }
}

Visual Studioなどで自動生成された名前のままにすると、役割がわかりません。

改善例です。

C#
public class TaxCalculator
{
    public decimal CalculateTax(decimal price)
    {
        return price * 0.1m;
    }
}

名前を付けるときは、「この名前だけを見て役割が伝わるか」を意識しましょう。

7. 用途別に見るC#命名パターン

7-1. DTO・Model・Entityの命名

DTOは、データ転送用のオブジェクトを表します。末尾に Dto を付けることが多いです。

C#
public class CustomerDto
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Modelは、アプリケーションの画面や処理で使うモデルを表します。

C#
public class CustomerModel
{
}

Entityは、データベースのテーブルに対応するオブジェクトとして使われることが多いです。

C#
public class CustomerEntity
{
}

ただし、プロジェクトによっては Customer のようにシンプルな名前をEntityとして使うこともあります。

7-2. Controller・Service・Repositoryの命名

ASP.NET Coreなどでは、Controller、Service、Repositoryという命名がよく使われます。

C#
public class CustomersController
{
}

public class CustomerService
{
}

public class CustomerRepository
{
}

Controllerはリクエストを受け取る役割、Serviceは業務ロジック、Repositoryはデータアクセスを担当することが多いです。

インターフェイスを使う場合は次のようにします。

C#
public interface ICustomerService
{
}

public class CustomerService : ICustomerService
{
}

7-3. Exceptionクラスの命名

例外クラスは、末尾に Exception を付けます。

C#
public class CustomerNotFoundException : Exception
{
}

public class InvalidOrderStatusException : Exception
{
}

何が原因の例外なのかがわかる名前にしましょう。

C#
throw new CustomerNotFoundException();

7-4. Testクラス・テストメソッドの命名

テストクラスは、対象クラス名に Tests を付けることが多いです。

C#
public class CustomerServiceTests
{
}

テストメソッド名は、チームやフレームワークによって流派があります。

C#
public void GetCustomer_WhenCustomerExists_ReturnsCustomer()
{
}

または日本語に近い説明的な名前を使う場合もあります。

C#
public void GetCustomer_存在する顧客IDを指定した場合_顧客を返す()
{
}

ただし、通常の本番コードでは日本語名を避けることが多いため、プロジェクトの方針に合わせましょう。

7-5. Unity開発でのC#命名規則

UnityでもC#命名規則の基本は同じです。

C#
public class PlayerController : MonoBehaviour
{
    private float _moveSpeed;

    private void Start()
    {
    }

    private void Update()
    {
    }
}

Unityでは、Start、Update、Awake など、Unity側から呼ばれる特別なメソッドがあります。これらはUnityの仕様に従った名前にする必要があります。

ゲームオブジェクトやコンポーネントの役割がわかるように、次のような名前を付けると読みやすくなります。

C#
PlayerController
EnemySpawner
GameScoreManager

7-6. LINQやラムダ式で使う変数名の考え方

LINQやラムダ式では、短い変数名が使われることがあります。

C#
var activeUsers = users.Where(u => u.IsActive);

ただし、意味がわかりにくくなる場合は、具体的な名前にしましょう。

C#
var activeUsers = users.Where(user => user.IsActive);

複雑な処理では、1文字よりも意味のある名前を使うほうが読みやすくなります。

C#
var expensiveOrders = orders
    .Where(order => order.TotalPrice > 10000)
    .OrderBy(order => order.OrderDate);

8. C#命名規則をチームで統一する方法

8-1. プロジェクトで命名ルールを決める手順

チームで命名規則を統一するには、まず対象を整理します。

クラス名、インターフェイス名、メソッド名、プロパティ名、変数名、privateフィールド名、定数名、テストメソッド名など、どこまでルール化するかを決めます。

特に議論になりやすいのは、privateフィールドにアンダースコアを付けるか、定数をPascalCaseにするか、テストメソッド名をどの形式にするかです。

最初から細かく決めすぎるより、よく使う部分からルール化すると運用しやすくなります。

8-2. コーディング規約として文書化する

命名規則は、口頭ではなく文書として残すことが重要です。

たとえば、次のように書いておきます。

クラス名: PascalCase
インターフェイス名: I + PascalCase
メソッド名: PascalCase
プロパティ名: PascalCase
ローカル変数: camelCase
メソッド引数: camelCase
privateフィールド: _camelCase
定数: PascalCase

README、社内Wiki、開発ガイドラインなどにまとめておくと、新しく参加したメンバーも迷いにくくなります。

8-3. 既存コードに合わせるべきケース

新しいルールを知っていても、既存コードと大きく違う命名をすると、かえって読みにくくなる場合があります。

たとえば、既存コードがprivateフィールドにアンダースコアを使っていない場合、新しく追加するコードだけアンダースコアを付けると統一感がなくなります。

実務では、理想的な命名規則よりも、プロジェクト内で一貫していることが優先されることがあります。

8-4. コードレビューで確認すべき命名ポイント

コードレビューでは、名前が役割を正しく表しているかを確認します。

たとえば、次のような観点です。

名前が抽象的すぎないか、処理内容とメソッド名が一致しているか、bool名がtrueの意味を表しているか、略語が多すぎないか、既存コードの命名規則と合っているかを確認します。

命名は主観が入りやすいため、指摘するときは「この名前は悪い」ではなく、「この名前のほうが意図が伝わりやすい」と説明すると、チーム内で合意しやすくなります。

8-5. 命名に迷ったときの判断基準

命名に迷ったときは、次の基準で考えると決めやすくなります。

まず、その名前だけで役割が伝わるかを確認します。次に、同じ種類の名前と形式がそろっているかを見ます。さらに、将来コードを読む人が誤解しないかを考えます。

たとえば、GetUser と FindUser で迷う場合、必ず存在する前提なら GetUser、存在しない可能性がある検索なら FindUser のように使い分けると意味が明確になります。

9. Visual Studio・EditorConfigで命名規則を自動チェックする方法

9-1. Visual Studioのコードスタイル設定

Visual Studioでは、コードスタイル設定で命名規則を管理できます。

たとえば、privateフィールドは _camelCase にする、インターフェイスは I で始める、クラス名はPascalCaseにする、といったルールを設定できます。

手作業だけで命名を統一するのは大変です。IDEの警告や提案を活用すると、命名ミスを早い段階で見つけやすくなります。

9-2. EditorConfigで命名規則を管理する

EditorConfigを使うと、プロジェクト単位で命名規則を共有できます。

.editorconfig にルールを書いておけば、チームメンバー全員が同じコードスタイルを使いやすくなります。

例です。

INI
[*.cs]

dotnet_naming_rule.private_fields_should_be_camel_case.severity = suggestion
dotnet_naming_rule.private_fields_should_be_camel_case.symbols = private_fields
dotnet_naming_rule.private_fields_should_be_camel_case.style = prefix_underscore

dotnet_naming_symbols.private_fields.applicable_kinds = field
dotnet_naming_symbols.private_fields.applicable_accessibilities = private

dotnet_naming_style.prefix_underscore.required_prefix = _
dotnet_naming_style.prefix_underscore.capitalization = camel_case

このように設定することで、privateフィールドにアンダースコアを付けるルールを共有できます。

9-3. Roslyn Analyzerで命名ミスを検出する

Roslyn Analyzerを使うと、C#コードを解析して命名規則違反やスタイル違反を検出できます。

Visual Studioの警告として表示したり、ビルド時にチェックしたりできます。

命名規則は人間の目だけで確認すると漏れが出やすいため、自動チェックを導入すると品質を保ちやすくなります。

9-4. StyleCopを使った命名規則チェック

StyleCopは、C#のコードスタイルをチェックするためによく使われるツールです。

命名規則、コメント、空白、メンバーの順序など、さまざまなルールをチェックできます。

特にチーム開発では、StyleCopやAnalyzerを導入することで、レビュー時に細かい命名指摘を減らし、本質的な設計やロジックの確認に集中しやすくなります。

9-5. 自動整形・警告を活用して命名を統一する

命名規則は、手動で守るだけでは限界があります。

Visual Studio、EditorConfig、Analyzer、StyleCopなどを組み合わせることで、命名のズレを自動的に検出できます。

さらに、CIで静的解析を実行すれば、ルール違反のコードがマージされる前に気づけます。

個人開発でもチーム開発でも、命名規則はツールで支援するのがおすすめです。

10. C#命名規則の早見表

10-1. クラス・インターフェイス・メソッドの命名早見表

10-2. 変数・フィールド・定数の命名早見表

10-3. PascalCaseとcamelCaseの使い分け早見表

PascalCaseを使う代表例です。

C#
CustomerService
GetCustomer
CustomerName
OrderStatus

camelCaseを使う代表例です。

C#
customerName
orderId
isActive
totalPrice

基本的には、型やメンバーにはPascalCase、メソッド内で使う変数や引数にはcamelCaseを使うと覚えるとわかりやすいです。

10-4. 初心者が覚えるべき最低限のルール

初心者が最初に覚えるべきC#命名規則は、次の4つです。

クラス名はPascalCase、メソッド名はPascalCase、プロパティ名はPascalCase、変数名と引数名はcamelCaseです。

これだけでも、かなりC#らしいコードになります。

C#
public class CustomerService
{
    public string CustomerName { get; set; }

    public void UpdateCustomerName(string customerName)
    {
        CustomerName = customerName;
    }
}

10-5. 実務で意識したい命名チェックリスト

実務では、次の点を意識すると命名の品質が上がります。

名前だけで役割が伝わるか、処理内容とメソッド名が合っているか、bool名が自然に読めるか、略語を使いすぎていないか、既存コードの命名と統一されているかを確認しましょう。

また、名前に迷うということは、クラスやメソッドの責務があいまいな可能性もあります。その場合は、命名だけでなく設計も見直すとよいでしょう。

11. C#命名規則に関するよくある質問

11-1. C#ではスネークケースを使ってもよい？

C#では、一般的にスネークケースはあまり使いません。

C#
// C#では一般的ではない
string customer_name;

通常はcamelCaseを使います。

C#
string customerName;

ただし、JSONのプロパティ名やデータベースのカラム名など、外部システムとの都合でスネークケースを扱うことはあります。その場合でも、C#コード内ではC#らしい命名にし、シリアライズ設定などで変換するのが一般的です。

11-2. privateフィールドにはアンダースコアを付けるべき？

privateフィールドにアンダースコアを付けるかどうかは、プロジェクトのルール次第です。

C#
private readonly ILogger _logger;

この形式は多くのC#プロジェクトで使われています。一方で、アンダースコアを使わない方針のプロジェクトもあります。

重要なのは、どちらかに統一することです。

11-3. 定数はすべて大文字にするべき？

C#では、定数をすべて大文字にするより、PascalCaseにするのが一般的です。

C#
public const int MaxRetryCount = 3;

MAX_RETRY_COUNT のような書き方は、CやJavaなど他の言語では見かけますが、C#ではあまり一般的ではありません。

11-4. メソッド名は動詞から始めるべき？

基本的には、メソッド名は動詞から始めるのがおすすめです。

C#
CreateUser
UpdateOrder
DeleteCustomer
CalculateTotalPrice
ValidateEmail

メソッドは処理を表すため、動詞を使うと役割が伝わりやすくなります。

ただし、変換系のメソッドでは ToString、ToList のような名前もあります。大切なのは、呼び出し側から見て何をするメソッドなのかが明確であることです。

11-5. 変数名に日本語を使ってもよい？

C#では、日本語の変数名を使うこと自体は可能です。

C#
string 顧客名 = "田中";

しかし、実務では英語の名前を使うことが一般的です。

C#
string customerName = "Tanaka";

英語にしておくと、ライブラリやフレームワークの命名とも統一しやすく、チームメンバーや将来の保守担当者にも伝わりやすくなります。

11-6. 命名規則に違反するとエラーになる？

命名規則に違反しても、基本的にはコンパイルエラーにはなりません。

C#
public class customer_service
{
}

このような名前でも、C#の構文として正しければコンパイルできる場合があります。

ただし、読みやすさや保守性は下がります。また、AnalyzerやStyleCopなどを導入している場合は、警告やエラーとして扱われることがあります。

11-7. 公式ルールと会社ルールが違う場合はどちらを優先する？

実務では、会社やプロジェクトのルールを優先するのが基本です。

コードは個人ではなくチームで保守するものです。公式ガイドラインを理解したうえで、プロジェクト内の一貫性を優先しましょう。

ただし、会社ルールが明らかに読みにくさや保守性を損なっている場合は、理由を整理して改善提案するのもよい方法です。

まとめ

C#命名規則は、読みやすく保守しやすいコードを書くための基本です。

まずは、クラス名・メソッド名・プロパティ名はPascalCase、ローカル変数・引数はcamelCaseという基本を押さえましょう。インターフェイスは I から始め、非同期メソッドには Async を付け、bool名には Is、Has、Can、Should などを使うと意味が伝わりやすくなります。

privateフィールドのアンダースコアやテストメソッド名などは、プロジェクトによってルールが異なることがあります。そのため、公式のC#命名規則を理解しつつ、実務では既存コードやチームの規約に合わせることが大切です。

命名は小さなことに見えますが、コードの品質を大きく左右します。名前を見ただけで役割が伝わるコードを意識して、読みやすいC#コードを書いていきましょう。