C#の命名規則を完全解説｜変数・クラス・メソッド名の付け方と実例

はじめに

C#で読みやすく保守しやすいコードを書くうえで、命名規則は非常に重要です。変数名、クラス名、メソッド名、プロパティ名などの名前は、コードの意図を伝えるための「説明文」として機能します。

同じ処理でも、名前の付け方が適切であれば、コメントが少なくても意味を理解しやすくなります。一方で、曖昧な名前やルールが統一されていない名前が多いと、コードレビューや機能追加、バグ修正のたびに余計な時間がかかります。

この記事では、C#の命名規則について、変数・クラス・メソッド・フィールド・プロパティ・定数などの要素別にわかりやすく解説します。実例も交えながら、現場で使いやすい命名の考え方を整理していきます。

1. C#の命名規則とは？まず押さえるべき基本

C#の命名規則とは、クラス名やメソッド名、変数名などに対して、どのような形式で名前を付けるかを決めるルールのことです。

C#では、言語仕様として「この名前でなければならない」と厳密に決められているわけではありません。しかし、.NETの公式ガイドラインや多くの開発現場で使われている慣習があり、それに沿うことで読みやすいコードを書きやすくなります。

1-1. 命名規則がコードの可読性・保守性に与える影響

命名規則が整っているコードは、処理の流れを追いやすくなります。

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

C#
var d = GetData();
var flg = true;
var list = GetUsers();

一方、次のように名前を付けると、何を表しているのかが明確になります。

C#
var user = GetUser();
var isActive = true;
var users = GetUsers();

名前が適切であれば、コードを読む人は「この変数は何を表しているのか」「このメソッドは何をするのか」をすぐに理解できます。結果として、バグの発見、仕様変更、リファクタリングがしやすくなります。

1-2. C#でよく使われる命名スタイルの種類

C#でよく使われる命名スタイルには、主に次のようなものがあります。

C#
// PascalCase
public class UserService
{
    public string UserName { get; set; }
}

// camelCase
var userName = "Taro";

// _camelCase
private readonly IUserRepository _userRepository;

// UPPER_CASE
const int MAX_RETRY_COUNT = 3;

C#では、クラス名やメソッド名、プロパティ名にはPascalCaseを使い、ローカル変数や引数にはcamelCaseを使うのが一般的です。

1-3. PascalCase・camelCase・UPPER_CASEの違い

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

C#
UserService
CalculateTotalPrice
CreatedAt

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

C#
userName
totalPrice
createdAt

UPPER_CASEは、すべて大文字で書き、単語をアンダースコアで区切る書き方です。

C#
MAX_RETRY_COUNT
DEFAULT_TIMEOUT
API_BASE_URL

ただし、C#では定数であってもPascalCaseを使うことが多く、JavaやC言語のように必ずUPPER_CASEにするとは限りません。

1-4. .NET公式ガイドラインと現場ルールの考え方

C#の命名規則を考えるときは、.NETの一般的な命名ガイドラインを基本にしつつ、チームやプロジェクトのルールに合わせることが大切です。

たとえば、privateフィールドにアンダースコアを付けるかどうかは、現場によって方針が分かれます。

C#
private readonly UserRepository _userRepository;

このような書き方を採用するチームもあれば、アンダースコアを使わないチームもあります。

重要なのは、どちらが絶対的に正しいかではなく、プロジェクト内で統一されていることです。命名規則は「個人の好み」ではなく、「チーム全体でコードを読みやすくするための約束」と考えましょう。

2. C#の命名規則一覧｜要素別の基本ルール

ここでは、C#でよく登場する要素ごとに、基本的な命名規則を整理します。

2-1. クラス名の命名規則

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

C#
public class User
{
}

public class OrderService
{
}

public class PaymentRequest
{
}

クラスは「もの」や「役割」を表すため、動詞ではなく名詞を使います。

悪い例は次のとおりです。

C#
public class GetUser
{
}

public class DoPayment
{
}

GetUserやDoPaymentは処理を表しているため、クラス名よりもメソッド名に適しています。

2-2. メソッド名の命名規則

メソッド名はPascalCaseで書き、動詞または動詞句にします。

C#
public User GetUser(int userId)
{
    // 処理
}

public void SendEmail(string address)
{
    // 処理
}

public decimal CalculateTotalPrice()
{
    // 処理
}

メソッドは処理や操作を表すため、「何をするのか」が伝わる名前にします。

2-3. 変数名・ローカル変数名の命名規則

ローカル変数名はcamelCaseで書きます。

C#
var userName = "Taro";
var totalPrice = 1200;
var createdAt = DateTime.Now;

変数名は短すぎず、意味が伝わる名前にすることが重要です。

C#
// 悪い例
var x = 1200;

// 良い例
var totalPrice = 1200;

ループカウンタなど、慣習的に意味が明確な場合はiやjを使っても問題ありません。

C#
for (int i = 0; i < users.Count; i++)
{
    Console.WriteLine(users[i].Name);
}

2-4. フィールド名の命名規則

privateフィールドは、camelCaseまたはアンダースコア付きの_camelCaseで書かれることが多いです。

C#
private readonly UserRepository _userRepository;
private int _retryCount;

特に依存性注入で受け取ったオブジェクトを保持する場合、アンダースコア付きのprivateフィールドはよく使われます。

C#
public class UserService
{
    private readonly IUserRepository _userRepository;

    public UserService(IUserRepository userRepository)
    {
        _userRepository = userRepository;
    }
}

2-5. プロパティ名の命名規則

プロパティ名はPascalCaseで書きます。

C#
public string UserName { get; set; }

public int Age { get; set; }

public DateTime CreatedAt { get; set; }

プロパティは外部から見えるメンバーであることが多いため、クラス名やメソッド名と同じくPascalCaseを使います。

2-6. 定数名の命名規則

C#では、定数名もPascalCaseで書くことが一般的です。

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

ただし、プロジェクトによっては次のようにUPPER_CASEを使う場合もあります。

C#
public const int MAX_RETRY_COUNT = 3;

C#らしい書き方としてはPascalCaseが推奨されることが多いですが、既存プロジェクトのルールに従うことが大切です。

2-7. インターフェース名の命名規則

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

C#
public interface IUserRepository
{
    User FindById(int userId);
}

public interface IEmailSender
{
    void Send(string address, string subject, string body);
}

Iを付けることで、クラスではなくインターフェースであることがすぐにわかります。

2-8. 列挙型・Enumの命名規則

列挙型の名前と値はPascalCaseで書きます。

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

列挙型名は単数形にするのが基本です。

C#
// 良い例
public enum UserRole
{
    Admin,
    Member,
    Guest
}

ただし、ビットフラグとして複数値を組み合わせるEnumでは、複数形を使うことがあります。

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

2-9. 名前空間・Namespaceの命名規則

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

C#
namespace MyCompany.ECommerce.Users
{
}

一般的には、次のような構成にします。

C#
CompanyName.ProductName.FeatureName

例としては、次のようになります。

C#
namespace SampleApp.Services
{
}

namespace SampleApp.Models
{
}

namespace SampleApp.Repositories
{
}

名前空間は、クラスの所属や責務を整理するためのものです。プロジェクト構造と対応させると、コードの場所を把握しやすくなります。

3. 変数名の付け方｜わかりやすい名前にする実践ルール

変数名は、コードの読みやすさに大きく影響します。特にC#では型推論のvarを使う場面も多いため、変数名から意味が伝わることが重要です。

3-1. 意味が伝わる変数名を付ける

変数名は、その値が何を表しているかがわかる名前にします。

C#
// 悪い例
var n = "Taro";
var p = 1200;

// 良い例
var userName = "Taro";
var productPrice = 1200;

短い名前は入力しやすい反面、後から読む人にとって意味が伝わりにくくなります。特に業務ロジックでは、多少長くても意味が明確な名前を優先しましょう。

3-2. 省略しすぎた名前を避ける

省略名は、チーム内で意味が共有されていないと読みにくくなります。

C#
// 悪い例
var usr = GetUser();
var addr = user.Address;
var cnt = users.Count;

次のように書くと、意味が明確になります。

C#
var user = GetUser();
var address = user.Address;
var userCount = users.Count;

idやurlなど、一般的に広く使われる略語は問題ありません。ただし、独自の略語や業務固有の略語は避けるか、チーム内でルールを決めて使いましょう。

3-3. 型名をそのまま変数名にしない

型名をそのまま変数名にすると、変数が何を表しているのかわかりにくくなる場合があります。

C#
// 悪い例
var stringValue = "Taro";
var intValue = 100;
var list = GetUsers();

より具体的な意味を持つ名前にします。

C#
var userName = "Taro";
var maxRetryCount = 100;
var users = GetUsers();

ただし、型名がそのまま概念を表している場合は例外です。

C#
User user = GetUser();
Order order = GetOrder();

このように、userやorderのような名前は自然でわかりやすいため問題ありません。

3-4. bool型はis・has・canを使う

bool型の変数やプロパティには、is、has、can、shouldなどを使うと意味が明確になります。

C#
var isActive = true;
var hasPermission = false;
var canEdit = true;
var shouldRetry = false;

悪い例は次のとおりです。

C#
var active = true;
var permission = false;
var edit = true;

これらはbool値なのか、状態名なのか、処理名なのかがわかりにくくなります。

bool型の名前は、条件文に入れたときに自然に読めるかを意識するとよいです。

C#
if (isActive)
{
    // 有効な場合の処理
}

if (hasPermission)
{
    // 権限がある場合の処理
}

3-5. コレクション変数は複数形にする

配列やリストなど、複数の要素を持つ変数は複数形にします。

C#
var users = GetUsers();
var products = GetProducts();
var orderItems = GetOrderItems();

単数形にすると、1件のデータなのか複数のデータなのかがわかりにくくなります。

C#
// 悪い例
var user = GetUsers();

// 良い例
var users = GetUsers();

Dictionaryの場合は、キーと値の関係がわかる名前にすると読みやすくなります。

C#
var userById = new Dictionary<int, User>();
var productsByCategory = new Dictionary<string, List<Product>>();

3-6. 悪い変数名と改善例

変数名の改善例を見てみましょう。

C#
// 悪い例
var d = DateTime.Now;
var u = GetUser();
var flg = user.IsActive;
var list = GetProducts();

改善すると、次のようになります。

C#
var currentDateTime = DateTime.Now;
var user = GetUser();
var isUserActive = user.IsActive;
var products = GetProducts();

さらに、処理の文脈に合わせて具体化すると、より読みやすくなります。

C#
var registeredAt = DateTime.Now;
var targetUser = GetUser(userId);
var isTargetUserActive = targetUser.IsActive;
var availableProducts = GetAvailableProducts();

命名では、「何の値なのか」「どのような状態なのか」「どの対象に関するものなのか」が伝わることを意識しましょう。

4. クラス名・メソッド名の付け方と実例

クラス名とメソッド名は、設計の意図を表す重要な要素です。名前が曖昧だと、責務が不明確なクラスや、何をしているかわからないメソッドが増えてしまいます。

4-1. クラス名は名詞・名詞句で表す

クラス名は、基本的に名詞または名詞句で表します。

C#
public class User
{
}

public class UserService
{
}

public class OrderRepository
{
}

public class PaymentRequest
{
}

クラスは「データ」「役割」「概念」を表すため、動詞よりも名詞が適しています。

C#
// 悪い例
public class CreateOrder
{
}

// 良い例
public class OrderFactory
{
}

4-2. メソッド名は動詞・動詞句で表す

メソッド名は、何らかの処理を行うため、動詞または動詞句で表します。

C#
public void CreateOrder()
{
}

public User FindUserById(int userId)
{
}

public decimal CalculateTotalPrice()
{
}

よく使われる動詞には、次のようなものがあります。

C#
Get
Find
Create
Update
Delete
Calculate
Validate
Send
Convert
Build

たとえば、ユーザーを取得するメソッドであれば、用途に応じて名前を変えます。

C#
GetUser()
FindUserById()
SearchUsers()
LoadUserProfile()

4-3. 責務が伝わる名前にする

クラス名やメソッド名は、責務が伝わる名前にすることが重要です。

C#
// 悪い例
public class UserManager
{
    public void Do()
    {
    }
}

この名前では、何を管理し、何を実行するのかがわかりません。

C#
// 良い例
public class UserRegistrationService
{
    public void RegisterUser(UserRegistrationRequest request)
    {
    }
}

UserRegistrationServiceであれば、ユーザー登録に関する処理を担当することがわかります。RegisterUserというメソッド名からも、ユーザーを登録する処理であることが明確です。

4-4. Manager・Helper・Utilを安易に使わない

Manager、Helper、Utilは便利な名前ですが、安易に使うと責務が曖昧になりやすいです。

C#
// 悪い例
public class UserManager
{
}

public class StringHelper
{
}

public class DateUtil
{
}

これらの名前は、クラスが大きくなりすぎる原因になることがあります。より具体的な責務を表す名前を検討しましょう。

C#
public class UserRegistrationService
{
}

public class PasswordHasher
{
}

public class DateRangeCalculator
{
}

ただし、プロジェクトの設計方針としてManagerやHelperを使っている場合は、完全に禁止する必要はありません。重要なのは、名前から責務が想像できるかどうかです。

4-5. 戻り値や処理内容が想像できるメソッド名にする

メソッド名は、戻り値や処理内容がある程度想像できる名前にします。

C#
// 悪い例
public User Execute(int id)
{
    // ユーザー取得
}

Executeだけでは、何を実行するのかわかりません。

C#
// 良い例
public User GetUserById(int userId)
{
    // ユーザー取得
}

また、真偽値を返すメソッドであれば、Is、Has、Canなどを使うと自然です。

C#
public bool IsValidEmail(string email)
{
}

public bool HasPermission(User user)
{
}

public bool CanDeleteOrder(Order order)
{
}

4-6. クラス名・メソッド名の悪い例と良い例

悪い例と良い例を比較してみましょう。

C#
// 悪い例
public class DataManager
{
    public void Process()
    {
    }

    public object Get(int id)
    {
        return null;
    }
}

改善例は次のとおりです。

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

    public Order GetOrderById(int orderId)
    {
        return new Order();
    }
}

さらに責務を分けると、より明確になります。

C#
public class OrderRepository
{
    public Order FindById(int orderId)
    {
        return new Order();
    }
}

public class OrderCompletionService
{
    public void Complete(int orderId)
    {
    }
}

名前を見ただけで役割が伝わるようにすることが、良い命名の基本です。

5. フィールド・プロパティ・定数の命名規則

C#では、フィールド、プロパティ、定数の使い分けも重要です。それぞれの役割に合わせて、適切な命名規則を使いましょう。

5-1. privateフィールドにアンダースコアを付けるべきか

privateフィールドにアンダースコアを付けるかどうかは、C#の命名規則でよく議論されるポイントです。

C#
private readonly IUserRepository _userRepository;

アンダースコアを付けるメリットは、ローカル変数やコンストラクタ引数と区別しやすいことです。

C#
public class UserService
{
    private readonly IUserRepository _userRepository;

    public UserService(IUserRepository userRepository)
    {
        _userRepository = userRepository;
    }
}

一方で、アンダースコアを使わずにthisを使う書き方もあります。

C#
public class UserService
{
    private readonly IUserRepository userRepository;

    public UserService(IUserRepository userRepository)
    {
        this.userRepository = userRepository;
    }
}

どちらを選ぶかはチームの方針次第です。ただし、同じプロジェクト内で混在させないことが重要です。

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

C#では、外部に公開する値にはpublicフィールドではなくプロパティを使うのが一般的です。

C#
// 避けたい例
public string UserName;

プロパティを使うと、後からバリデーションや読み取り専用化などの制御を追加しやすくなります。

C#
public string UserName { get; set; }

読み取り専用にしたい場合は、次のように書けます。

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

外部公開するデータは、基本的にプロパティとして表現しましょう。

5-3. プロパティ名はPascalCaseにする

プロパティ名はPascalCaseで書きます。

C#
public class User
{
    public int UserId { get; set; }

    public string UserName { get; set; }

    public DateTime RegisteredAt { get; set; }

    public bool IsActive { get; set; }
}

bool型のプロパティでは、状態がわかる名前を付けます。

C#
public bool IsDeleted { get; set; }

public bool HasAdminRole { get; set; }

public bool CanLogin { get; set; }

5-4. const・readonly・static readonlyの命名ルール

const、readonly、static readonlyはいずれも値の変更を制限するために使いますが、用途が異なります。

C#
public const int MaxRetryCount = 3;

private readonly IUserRepository _userRepository;

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

constはコンパイル時に値が決まる定数に使います。

C#
public const int MaxLength = 100;

readonlyは、コンストラクタで初期化した後に変更しないフィールドに使います。

C#
private readonly string _connectionString;

static readonlyは、実行時に生成される固定値などに使います。

C#
public static readonly DateTime ServiceStartDate = DateTime.UtcNow;

命名としては、C#ではPascalCaseを使うことが多いです。

5-5. 定数名を大文字スネークケースにするべきか

他の言語では、定数名を大文字スネークケースにすることがあります。

C#
public const int MAX_RETRY_COUNT = 3;

しかし、C#ではpublicメンバーにPascalCaseを使う文化が強いため、次のように書くことが一般的です。

C#
public const int MaxRetryCount = 3;

ただし、既存プロジェクトでUPPER_CASEが採用されている場合は、そのルールに合わせるべきです。命名規則では、個々の好みよりも一貫性が重要です。

5-6. フィールド・プロパティ・定数の実例

フィールド、プロパティ、定数を含むクラスの例を見てみましょう。

C#
public class LoginService
{
    private const int MaxRetryCount = 3;

    private readonly IUserRepository _userRepository;
    private readonly IPasswordHasher _passwordHasher;

    public LoginService(
        IUserRepository userRepository,
        IPasswordHasher passwordHasher)
    {
        _userRepository = userRepository;
        _passwordHasher = passwordHasher;
    }

    public bool CanLogin { get; private set; }

    public bool Login(string email, string password)
    {
        var user = _userRepository.FindByEmail(email);

        if (user == null)
        {
            return false;
        }

        return _passwordHasher.Verify(password, user.PasswordHash);
    }
}

この例では、privateフィールドは_camelCase、publicプロパティはPascalCase、ローカル変数はcamelCaseで統一されています。

6. C#で間違えやすい命名規則と注意点

C#の命名規則では、基本ルールを知っていても間違えやすいポイントがあります。特に、古い書き方や他言語の習慣をそのまま持ち込むと、C#らしくないコードになることがあります。

6-1. ハンガリアン記法を避ける

ハンガリアン記法とは、変数名に型情報を含める命名方法です。

C#
// 避けたい例
string strUserName;
int intAge;
bool blnIsActive;

C#では型が明確にわかるため、変数名に型情報を入れる必要はほとんどありません。

C#
// 良い例
string userName;
int age;
bool isActive;

型ではなく、値の意味を名前に含めることを意識しましょう。

6-2. 日本語ローマ字の命名を避ける

日本語をローマ字にした名前は、英語圏の開発者だけでなく、日本人にとっても読みにくくなることがあります。

C#
// 避けたい例
var shohinList = GetProducts();
var kingaku = 1000;
var kokyakuName = "Taro";

英語で意味が伝わる名前にしましょう。

C#
var products = GetProducts();
var amount = 1000;
var customerName = "Taro";

業務用語として日本語の概念が強い場合でも、チーム内で英語名を定義しておくと命名が安定します。

6-3. 略語・頭字語の扱い方

略語や頭字語は、使い方に注意が必要です。

C#
var userId = 1;
var apiUrl = "https://example.com";

Id、Url、Apiのような略語は、C#ではPascalCaseやcamelCaseのルールに合わせて扱うことが多いです。

C#
public string ApiUrl { get; set; }

public int UserId { get; set; }

public string HtmlContent { get; set; }

すべて大文字にすると、読みづらくなる場合があります。

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

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

6-4. asyncメソッドにはAsyncを付ける

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

C#
public async Task<User> GetUserAsync(int userId)
{
    return await _userRepository.FindByIdAsync(userId);
}

Asyncを付けることで、呼び出し側が非同期処理であることを判断しやすくなります。

C#
var user = await GetUserAsync(userId);

同期メソッドと非同期メソッドが両方ある場合も、名前で区別できます。

C#
public User GetUser(int userId)
{
}

public Task<User> GetUserAsync(int userId)
{
}

6-5. イベント名・イベントハンドラー名の付け方

イベント名はPascalCaseで、発生する出来事を表す名前にします。

C#
public event EventHandler OrderCompleted;
public event EventHandler<UserCreatedEventArgs> UserCreated;

イベントハンドラー名は、一般的に「対象_イベント名」の形式で書かれることがあります。

C#
private void Button_Click(object sender, EventArgs e)
{
}

また、イベントを発生させるメソッドにはOnを付けることがあります。

C#
protected virtual void OnOrderCompleted(EventArgs e)
{
    OrderCompleted?.Invoke(this, e);
}

イベント名は、過去形や完了形を使うと「何が起きたのか」が伝わりやすくなります。

C#
OrderCreated
PaymentCompleted
UserDeleted

6-6. ジェネリック型パラメーターの命名ルール

ジェネリック型パラメーターには、Tを使うのが一般的です。

C#
public class Repository<T>
{
}

複数の型パラメーターがある場合や、意味を明確にしたい場合は、Tから始まる名前を付けます。

C#
public class Mapper<TSource, TDestination>
{
}

public interface IRepository<TEntity>
{
}

T1、T2のような名前でも動作しますが、意味が伝わりにくいため、できるだけ役割がわかる名前にしましょう。

C#
// 避けたい例
public class Converter<T1, T2>
{
}

// 良い例
public class Converter<TSource, TResult>
{
}

7. チーム開発で命名規則を統一する方法

命名規則は、個人で意識するだけでは限界があります。チーム開発では、ドキュメント化やツールによる自動チェックを活用して、命名のブレを減らすことが重要です。

7-1. コーディング規約をドキュメント化する

まずは、プロジェクトの命名ルールを明文化しましょう。

たとえば、次のような項目を決めておくと便利です。

- クラス名はPascalCase
- メソッド名はPascalCase
- ローカル変数はcamelCase
- privateフィールドは_camelCase
- インターフェース名はIで始める
- 非同期メソッドにはAsyncを付ける
- bool型はis、has、can、shouldを使う

ルールをドキュメント化しておくと、新しいメンバーが参加したときにも説明しやすくなります。

7-2. .editorconfigで命名規則を設定する

C#では、.editorconfigを使って命名規則を設定できます。

たとえば、privateフィールドにアンダースコアを付けるルールを設定できます。

INI
[*.cs]

dotnet_naming_rule.private_fields_should_be_camel_case.severity = warning
dotnet_naming_rule.private_fields_should_be_camel_case.symbols = private_fields
dotnet_naming_rule.private_fields_should_be_camel_case.style = underscore_camel_case

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

dotnet_naming_style.underscore_camel_case.required_prefix = _
dotnet_naming_style.underscore_camel_case.capitalization = camel_case

.editorconfigをリポジトリに含めておくことで、メンバー間で同じルールを共有できます。

7-3. Visual Studioのコード分析を活用する

Visual Studioでは、命名規則やコードスタイルに関する警告を表示できます。

たとえば、設定した命名規則に違反している場合、警告や提案として表示されます。これにより、コードレビュー前に命名のブレを発見しやすくなります。

また、クイックアクションを使って名前を変更できるため、リファクタリングも安全に行えます。

C#
// 変更前
private readonly IUserRepository userRepository;

// 変更後
private readonly IUserRepository _userRepository;

IDEの機能を活用することで、手作業でのチェックを減らせます。

7-4. StyleCop・Roslyn Analyzerで自動チェックする

StyleCopやRoslyn Analyzerを導入すると、命名規則やコードスタイルを自動でチェックできます。

たとえば、次のようなルールを検出できます。

- publicメンバーがPascalCaseになっていない
- privateフィールドの命名規則が統一されていない
- メソッド名が不適切
- 非同期メソッドにAsyncが付いていない

CI環境でAnalyzerを実行すれば、ルールに違反したコードがマージされる前に検出できます。

7-5. レビューで命名のブレを減らすポイント

コードレビューでは、命名について次の観点で確認すると効果的です。

- 名前から役割が伝わるか
- 既存コードと命名ルールが揃っているか
- 省略しすぎていないか
- bool型の名前が自然に読めるか
- クラスやメソッドの責務が名前に表れているか

ただし、命名の指摘は主観的になりやすいため、チームで決めたルールに基づいてレビューすることが大切です。

8. C#命名規則の実践例｜よくあるケース別サンプル

ここでは、実際の開発でよくあるケースをもとに、C#の命名規則の実例を紹介します。

8-1. ユーザー情報を扱うクラスの命名例

ユーザー情報を表すクラスでは、クラス名は名詞、プロパティはPascalCaseで書きます。

C#
public class User
{
    public int UserId { get; set; }

    public string UserName { get; set; }

    public string Email { get; set; }

    public bool IsActive { get; set; }

    public DateTime RegisteredAt { get; set; }
}

登録リクエストを表すクラスであれば、用途がわかる名前にします。

C#
public class UserRegistrationRequest
{
    public string UserName { get; set; }

    public string Email { get; set; }

    public string Password { get; set; }
}

レスポンス用であれば、次のようにします。

C#
public class UserResponse
{
    public int UserId { get; set; }

    public string UserName { get; set; }

    public string Email { get; set; }
}

8-2. データ取得メソッドの命名例

データ取得メソッドでは、取得条件や戻り値が想像できる名前にします。

C#
public User GetUserById(int userId)
{
}

public IReadOnlyList<User> GetActiveUsers()
{
}

public User FindUserByEmail(string email)
{
}

public async Task<User> GetUserByIdAsync(int userId)
{
}

GetとFindはプロジェクトによって使い分けが異なりますが、たとえば次のようにルール化できます。

Get: 存在する前提で取得する
Find: 存在しない可能性があるものを検索する
Search: 複数条件で検索する

このように意味を決めておくと、メソッド名のブレを減らせます。

8-3. フラグ変数・boolプロパティの命名例

bool型の変数やプロパティでは、条件文で自然に読める名前にします。

C#
var isActive = user.IsActive;
var hasPermission = permissionService.HasPermission(user);
var canEdit = user.Role == UserRole.Admin;
var shouldSendEmail = user.EmailConfirmed;

プロパティの場合も同様です。

C#
public bool IsActive { get; set; }

public bool IsDeleted { get; set; }

public bool HasPermission { get; set; }

public bool CanEdit { get; set; }

メソッドで判定する場合は、次のようにします。

C#
public bool IsValidEmail(string email)
{
}

public bool CanCancelOrder(Order order)
{
}

public bool HasEnoughStock(Product product, int quantity)
{
}

8-4. リスト・配列・Dictionaryの命名例

複数件を表すコレクションは複数形にします。

C#
var users = new List<User>();
var products = new Product[10];
var orders = GetOrders();

条件がある場合は、より具体的にします。

C#
var activeUsers = GetActiveUsers();
var expiredOrders = GetExpiredOrders();
var availableProducts = GetAvailableProducts();

Dictionaryでは、キーとの関係がわかる名前にすると便利です。

C#
var userById = new Dictionary<int, User>();

var productsByCategory = new Dictionary<string, List<Product>>();

var orderCountByUserId = new Dictionary<int, int>();

Dictionaryだからといって、単にdictionaryという変数名にするのは避けましょう。

C#
// 悪い例
var dictionary = new Dictionary<int, User>();

// 良い例
var userById = new Dictionary<int, User>();

8-5. API・DTO・ViewModelの命名例

APIやWebアプリケーションでは、DTO、Request、Response、ViewModelなどの名前を使うことがあります。

C#
public class CreateUserRequest
{
    public string UserName { get; set; }

    public string Email { get; set; }
}

public class CreateUserResponse
{
    public int UserId { get; set; }

    public DateTime CreatedAt { get; set; }
}

DTOの場合は、用途がわかる名前にします。

C#
public class UserDto
{
    public int UserId { get; set; }

    public string UserName { get; set; }
}

画面表示用のモデルであれば、ViewModelを付けると役割が明確になります。

C#
public class UserDetailViewModel
{
    public string UserName { get; set; }

    public string Email { get; set; }

    public bool CanEdit { get; set; }
}

APIクライアントの名前も、対象がわかるようにします。

C#
public class UserApiClient
{
}

public class PaymentApiClient
{
}

8-6. 命名改善のビフォーアフター

最後に、命名改善の例をまとめて見てみましょう。

C#
// Before
public class DataManager
{
    public object Get(int id)
    {
        var d = Load(id);
        return d;
    }

    public bool Check(object obj)
    {
        return obj != null;
    }
}

このコードでは、クラス名、メソッド名、変数名の意味が曖昧です。

C#
// After
public class UserRepository
{
    public User FindById(int userId)
    {
        var user = LoadUser(userId);
        return user;
    }

    public bool Exists(User user)
    {
        return user != null;
    }
}

さらに、用途が明確であれば、次のようにもできます。

C#
public class UserQueryService
{
    public User GetActiveUserById(int userId)
    {
        var user = FindUserById(userId);

        if (user == null || !user.IsActive)
        {
            return null;
        }

        return user;
    }
}

命名を改善するだけで、コードの意図がかなり読み取りやすくなります。

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

ここでは、C#の命名規則に関してよくある疑問に回答します。

9-1. C#の変数名はcamelCaseとPascalCaseのどちらを使うべき？

ローカル変数やメソッド引数にはcamelCaseを使うのが一般的です。

C#
public void UpdateUserName(int userId, string userName)
{
    var updatedAt = DateTime.Now;
}

一方、プロパティ、メソッド、クラス、publicメンバーにはPascalCaseを使います。

C#
public string UserName { get; set; }

public void UpdateUserName()
{
}

基本的には、外部から見えるメンバーはPascalCase、メソッド内部の変数や引数はcamelCaseと覚えるとよいでしょう。

9-2. private変数にアンダースコアは必要？

privateフィールドにアンダースコアを付けるかどうかは、チームやプロジェクトのルールによります。

C#
private readonly IUserRepository _userRepository;

この形式は、C#の現場でよく使われています。コンストラクタ引数やローカル変数と区別しやすいというメリットがあります。

ただし、アンダースコアを付けないルールのプロジェクトもあります。

C#
private readonly IUserRepository userRepository;

大切なのは、プロジェクト内で統一することです。

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

C#では、定数名を必ずすべて大文字にする必要はありません。むしろ、PascalCaseを使うことが多いです。

C#
public const int MaxRetryCount = 3;

ただし、既存コードで大文字スネークケースが採用されている場合は、そのルールに合わせましょう。

C#
public const int MAX_RETRY_COUNT = 3;

新規プロジェクトでは、C#らしいPascalCaseで統一するのがおすすめです。

9-4. メソッド名にGet・Set・Createは使ってよい？

使って問題ありません。ただし、処理内容に合った動詞を選ぶことが大切です。

C#
public User GetUserById(int userId)
{
}

public void SetUserName(string userName)
{
}

public Order CreateOrder(CreateOrderRequest request)
{
}

ただし、GetDataやCreateObjectのように対象が曖昧な名前は避けましょう。

C#
// 悪い例
public object GetData()
{
}

// 良い例
public UserProfile GetUserProfile(int userId)
{
}

9-5. 命名規則に違反してもコンパイルできる？

多くの場合、命名規則に違反してもコンパイルはできます。

C#
public class user_service
{
    public void get_user()
    {
    }
}

このようなコードでも、C#の構文として正しければコンパイルは可能です。

ただし、命名規則に違反していると、可読性や保守性が下がります。また、コード分析ツールや.editorconfigの設定によっては、警告やエラーとして扱われる場合もあります。

命名規則はコンパイルのためではなく、チームで読みやすいコードを維持するためのルールです。

9-6. 既存コードの命名を直すときの注意点

既存コードの命名を修正するときは、影響範囲に注意しましょう。

特にpublicなクラス名、メソッド名、プロパティ名を変更すると、他のプロジェクトや外部API利用者に影響する可能性があります。

C#
// 変更前
public User GetUser(int id)
{
}

// 変更後
public User GetUserById(int userId)
{
}

内部だけで使われているprivateメソッドやローカル変数であれば、比較的安全に変更できます。

C#
// 変更前
var d = DateTime.Now;

// 変更後
var currentDateTime = DateTime.Now;

リファクタリング機能を使えば、参照箇所もまとめて変更できます。既存コードを直すときは、一度に大量の変更をするよりも、機能追加や修正のタイミングで少しずつ改善するのがおすすめです。

まとめ

C#の命名規則は、コードの可読性と保守性を高めるために欠かせないルールです。

基本的には、クラス名、メソッド名、プロパティ名、Enum名、名前空間にはPascalCaseを使い、ローカル変数や引数にはcamelCaseを使います。privateフィールドには_camelCaseを使うことが多いですが、チームのルールに合わせて統一することが重要です。

変数名は意味が伝わる名前にし、bool型にはis、has、can、shouldなどを使うと読みやすくなります。クラス名は名詞・名詞句、メソッド名は動詞・動詞句にすると、役割や処理内容が自然に伝わります。

また、Manager、Helper、Utilのような曖昧な名前や、ハンガリアン記法、日本語ローマ字、過度な省略は避けるべきです。非同期メソッドにはAsyncを付け、インターフェースにはIを付けるなど、C#で広く使われる慣習も押さえておきましょう。

チーム開発では、命名規則をドキュメント化し、.editorconfig、Visual Studioのコード分析、StyleCop、Roslyn Analyzerなどを活用すると、命名のブレを減らせます。

C#の命名規則で最も大切なのは、「名前を見ただけで意図が伝わること」と「プロジェクト内で一貫していること」です。正しい命名を意識することで、読みやすく、変更に強いC#コードを書けるようになります。