C#のクラス名命名規則を完全解説|PascalCase・名詞の使い方・NG例までわかる初心者ガイド
はじめに
C#でクラスを作るとき、意外と迷いやすいのが「クラス名をどう付けるか」です。プログラム自体は動いても、クラス名がわかりにくいと、あとから読んだときに処理の目的が理解しづらくなります。
C#のクラス名には、一般的に守るべき命名規則があります。代表的なものが、PascalCaseで書くこと、名詞または名詞句を使うこと、役割が伝わる具体的な名前にすることです。
たとえば、User、OrderService、CustomerRepository のような名前は、C#らしいクラス名としてよく使われます。一方で、user_data、getUser、Mgr のような名前は、C#のクラス名としては避けたほうがよいケースが多いです。
この記事では、C#のクラス名命名規則について、PascalCaseの使い方、名詞の考え方、良い例・悪い例、用途別の命名パターン、初心者が迷いやすいポイントまでわかりやすく解説します。
1. C#のクラス名命名規則でまず押さえる基本ルール
C#のクラス名を付けるときは、まず基本となるルールを押さえることが大切です。細かい例外やチームごとの規約はありますが、初心者は次の考え方を覚えておけば大きく外すことはありません。
1-1. クラス名はPascalCaseで書く
C#のクラス名は、基本的にPascalCaseで書きます。
PascalCaseとは、単語の先頭をすべて大文字にする書き方です。
C#public class User
{
}
public class OrderService
{
}
public class CustomerRepository
{
}
User のように1語の場合は先頭を大文字にします。OrderService のように複数の単語をつなげる場合は、各単語の先頭を大文字にします。
次のような書き方は、C#のクラス名としては一般的ではありません。
C#public class user
{
}
public class orderService
{
}
public class customer_repository
{
}
C#では、クラス名、構造体名、インターフェイス名、列挙型名など、多くの型名にPascalCaseを使うのが一般的です。
1-2. クラス名には名詞・名詞句を使う
クラス名には、基本的に名詞または名詞句を使います。
クラスは「もの」や「概念」を表すことが多いため、名前も名詞にするのが自然です。
C#public class User
{
}
public class Product
{
}
public class Invoice
{
}
また、役割を表す単語を組み合わせて名詞句にすることもよくあります。
C#public class UserService
{
}
public class OrderRepository
{
}
public class LoginViewModel
{
}
一方で、動詞から始まる名前はクラス名として不自然になりやすいです。
C#public class GetUser
{
}
public class CreateOrder
{
}
GetUser や CreateOrder は、クラス名というよりメソッド名に近い印象になります。
1-3. 役割が伝わる具体的な名前にする
クラス名は、そのクラスが何を表しているのか、どんな責務を持っているのかが伝わる名前にすることが重要です。
たとえば、ユーザー情報を表すクラスなら次のような名前が自然です。
C#public class User
{
}
ユーザーに関する処理をまとめるクラスなら、次のように役割を加えます。
C#public class UserService
{
}
データベースからユーザーを取得・保存するクラスなら、次のような名前が考えられます。
C#public class UserRepository
{
}
単に Data や Manager のような名前にすると、何を扱うクラスなのかがわかりにくくなります。
C#public class Data
{
}
public class Manager
{
}
クラス名は、コードを読む人にとっての案内板のようなものです。名前を見ただけで目的がある程度わかるようにしましょう。
1-4. 省略形や意味の曖昧な名前は避ける
クラス名では、意味のわかりにくい省略形を避けるのが基本です。
C#public class Usr
{
}
public class OrdMgr
{
}
public class CstRepo
{
}
書いた本人は Usr が User、OrdMgr が OrderManager の意味だとわかっていても、他の人が読むとすぐには理解できない場合があります。
C#では、少し長くなっても意味が明確な名前を優先したほうが、保守しやすいコードになります。
C#public class User
{
}
public class OrderManager
{
}
public class CustomerRepository
{
}
ただし、Id、Xml、Http、Dto など、プロジェクト内や業界で広く使われている略語は使われることがあります。その場合でも、表記をチーム内で統一することが大切です。
1-5. 初心者が最初に覚えるべきクラス名の考え方
初心者がC#のクラス名で迷ったときは、次の順番で考えると決めやすくなります。
まず、そのクラスが「何を表すのか」を考えます。ユーザーを表すなら User、商品を表すなら Product、注文を表すなら Order です。
次に、そのクラスに特別な役割があるかを考えます。処理を担当するなら Service、データアクセスを担当するなら Repository、画面表示用のデータなら ViewModel のような単語を加えます。
最後に、PascalCaseに整えます。
C#User
Product
Order
UserService
ProductRepository
OrderViewModel
最初から完璧な名前を付けようとしすぎる必要はありません。大切なのは、C#の命名規則に沿って、読みやすく、意味が伝わる名前にすることです。
2. PascalCaseとは?C#のクラス名で使う表記ルール
C#のクラス名命名規則を理解するうえで、PascalCaseは必ず押さえておきたい表記ルールです。
2-1. PascalCaseの意味と書き方
PascalCaseとは、単語の先頭を大文字にして、単語同士を区切り文字なしでつなげる書き方です。
C#User
Order
Product
UserService
OrderRepository
ProductController
UserService は、User と Service という2つの単語をつなげています。それぞれの単語の先頭が大文字になっているため、PascalCaseです。
C#のクラス名では、このPascalCaseが標準的な書き方として使われます。
2-2. PascalCaseとcamelCaseの違い
PascalCaseと似た表記に、camelCaseがあります。
PascalCaseは最初の単語も大文字で始めます。
C#UserService
OrderRepository
CustomerName
camelCaseは、最初の単語だけ小文字で始め、2語目以降の先頭を大文字にします。
C#userService
orderRepository
customerName
C#では、クラス名にはPascalCaseを使い、ローカル変数や引数にはcamelCaseを使うことが多いです。
C#public class UserService
{
public void RegisterUser(string userName)
{
var userId = 1;
}
}
この例では、UserService はクラス名なのでPascalCase、userName や userId は変数名なのでcamelCaseです。
2-3. PascalCaseとsnake_caseの違い
snake_caseは、単語をアンダースコアで区切る書き方です。
C#user_service
order_repository
customer_name
Pythonなどではよく使われますが、C#のクラス名では一般的ではありません。
C#でクラス名を書くなら、次のようにPascalCaseにするのが基本です。
C#UserService
OrderRepository
CustomerName
アンダースコアを使ったクラス名は、C#の標準的な命名規則から外れて見えるため、特別な理由がない限り避けましょう。
2-4. C#でクラス名にPascalCaseを使う理由
C#でクラス名にPascalCaseを使う理由は、コード全体の読みやすさを保つためです。
クラス名、メソッド名、プロパティ名などに一定の表記ルールがあると、コードを見たときに「これは型名だ」「これは変数名だ」と判断しやすくなります。
C#public class OrderService
{
public Order GetOrder(int orderId)
{
return new Order();
}
}
この例では、OrderService と Order が型名であることがすぐにわかります。一方で、orderId は変数名として自然に読めます。
命名規則は、コンパイラのためだけではなく、人間がコードを読みやすくするためのルールです。
2-5. PascalCaseのOK例・NG例
PascalCaseのOK例は次のとおりです。
C#public class User
{
}
public class UserProfile
{
}
public class OrderService
{
}
public class CustomerRepository
{
}
一方、次のような名前はNG例です。
C#public class user
{
}
public class userProfile
{
}
public class user_profile
{
}
public class USERPROFILE
{
}
user は小文字で始まっているため、C#のクラス名としては不自然です。userProfile はcamelCaseです。user_profile はsnake_caseです。USERPROFILE はすべて大文字で、単語の区切りがわかりにくくなります。
C#のクラス名では、基本的に UserProfile のようなPascalCaseを使いましょう。
3. C#のクラス名は「名詞」で付けるのが基本
C#のクラス名は、表記だけでなく品詞も重要です。基本は名詞です。
3-1. クラス名に名詞を使う理由
クラスは、オブジェクトの設計図です。多くの場合、ユーザー、商品、注文、請求書、設定、結果など、何らかの「もの」や「概念」を表します。
そのため、クラス名には名詞を使うのが自然です。
C#public class User
{
}
public class Product
{
}
public class PaymentResult
{
}
名詞にすることで、そのクラスが何を表しているのかがわかりやすくなります。
3-2. 「User」「Order」「Customer」のような名詞の例
シンプルなモデルクラスでは、単独の名詞を使うことがよくあります。
C#public class User
{
public int Id { get; set; }
public string Name { get; set; }
}
public class Order
{
public int Id { get; set; }
public DateTime OrderedAt { get; set; }
}
public class Customer
{
public int Id { get; set; }
public string Email { get; set; }
}
User、Order、Customer は、それぞれユーザー、注文、顧客という概念を表しています。
このように、データや概念を表すクラスでは、余計な単語を付けずに名詞だけで表すとシンプルです。
3-3. 「UserService」「OrderRepository」のような名詞句の例
クラスが特定の役割を持つ場合は、名詞に役割を表す単語を加えて名詞句にします。
C#public class UserService
{
}
public class OrderRepository
{
}
public class CustomerValidator
{
}
UserService はユーザーに関する処理を担当するクラス、OrderRepository は注文データの保存や取得を担当するクラス、CustomerValidator は顧客情報の検証を担当するクラスだとわかります。
名詞句を使うことで、対象と役割を同時に表せます。
3-4. メソッド名との違い:クラス名は名詞、メソッド名は動詞
C#では、クラス名とメソッド名で考え方が異なります。
クラス名は名詞にするのが基本です。
C#public class UserService
{
}
一方、メソッド名は動作を表すため、動詞または動詞句にすることが多いです。
C#public class UserService
{
public void RegisterUser()
{
}
public User GetUser()
{
return new User();
}
}
UserService は「何か」を表す名前、RegisterUser や GetUser は「何をするか」を表す名前です。
この違いを意識すると、クラス名とメソッド名を混同しにくくなります。
3-5. 動詞から始まるクラス名がNGになりやすい理由
動詞から始まるクラス名は、処理そのものを表しているように見えるため、クラス名として不自然になりやすいです。
C#public class GetUser
{
}
public class SaveOrder
{
}
public class CalculatePrice
{
}
これらは、クラス名というよりメソッド名に見えます。
改善するなら、役割に応じて次のようにします。
C#public class UserRepository
{
public User GetUser(int id)
{
return new User();
}
}
public class OrderRepository
{
public void SaveOrder(Order order)
{
}
}
public class PriceCalculator
{
public decimal CalculatePrice()
{
return 0;
}
}
処理名をそのままクラス名にするのではなく、「その処理を担当するもの」として名詞化するのがポイントです。
4. C#のクラス名の良い例と悪い例
クラス名の良し悪しは、実際の例を見ると理解しやすくなります。
4-1. 良いクラス名の条件
良いクラス名には、次のような特徴があります。
1つ目は、PascalCaseで書かれていることです。
C#UserProfile
OrderService
PaymentResult
2つ目は、名詞または名詞句になっていることです。
C#Customer
CustomerService
CustomerRepository
3つ目は、役割が具体的に伝わることです。
C#EmailSender
PasswordValidator
InvoiceCalculator
名前を見ただけで「何を表しているクラスか」「どんな責務を持っているクラスか」が想像できる名前は、良いクラス名です。
4-2. 悪いクラス名に共通する特徴
悪いクラス名には、次のような共通点があります。
意味が曖昧です。
C#Data
Info
Manager
短すぎて内容がわかりません。
C#A
Tmp
Obj
省略しすぎています。
C#UsrSvc
OrdRepo
CustVal
表記ルールがC#らしくありません。
C#user_service
orderrepository
CUSTOMERDATA
これらの名前は、コードを読む人に余計な負担をかけます。
4-3. 意味が曖昧なクラス名のNG例
特に注意したいのが、意味が広すぎるクラス名です。
C#public class Data
{
}
public class Info
{
}
public class Common
{
}
public class Utility
{
}
Data は何のデータなのか、Info は何の情報なのかがわかりません。Common や Utility は便利に見えますが、何でも入れられるクラスになりやすく、責務が曖昧になります。
改善するなら、対象や役割を具体的にします。
C#public class UserData
{
}
public class ProductInfo
{
}
public class DateTimeUtility
{
}
ただし、UserData や ProductInfo も場合によっては曖昧です。より具体的にできるなら、次のようにします。
C#public class UserProfile
{
}
public class ProductSummary
{
}
public class DateTimeFormatter
{
}
4-4. 長すぎるクラス名・短すぎるクラス名のNG例
クラス名は、短ければよいわけではありません。
C#public class U
{
}
public class Mgr
{
}
public class Proc
{
}
短すぎる名前は、意味が伝わりません。
一方で、長すぎる名前も読みにくくなります。
C#public class UserRegistrationAndEmailNotificationAndPointGrantService
{
}
この名前は、複数の責務を1つのクラスが持っている可能性があります。クラス名が極端に長くなる場合は、名前の問題だけでなく、クラスの責務が大きすぎないかも見直しましょう。
分割するなら、次のような名前が考えられます。
C#public class UserRegistrationService
{
}
public class EmailNotificationService
{
}
public class PointGrantService
{
}
4-5. 修正前・修正後で見るクラス名の改善例
悪いクラス名を改善する例を見てみましょう。
C#// 修正前
public class Data
{
}
// 修正後
public class UserProfile
{
}
何のデータなのかを明確にしています。
C#// 修正前
public class GetOrder
{
}
// 修正後
public class OrderRepository
{
}
動詞から始まる名前を、役割を表す名詞句に変更しています。
C#// 修正前
public class user_service
{
}
// 修正後
public class UserService
{
}
snake_caseをPascalCaseに直しています。
C#// 修正前
public class UsrMgr
{
}
// 修正後
public class UserManager
{
}
省略形を避けて、意味が伝わる名前にしています。
5. 用途別に見るC#のクラス名命名パターン
C#では、クラスの用途によってよく使われる命名パターンがあります。ここでは代表的な例を紹介します。
5-1. モデルクラスの命名例
モデルクラスは、データや概念を表すクラスです。基本的にはシンプルな名詞を使います。
C#public class User
{
}
public class Product
{
}
public class Order
{
}
public class Customer
{
}
必要に応じて、より具体的な名前にすることもあります。
C#public class UserProfile
{
}
public class ProductCategory
{
}
public class OrderDetail
{
}
モデルクラスでは、UserData や OrderInfo のような曖昧な名前より、何を表しているかが明確な名前を選ぶことが大切です。
5-2. サービスクラスの命名例
サービスクラスは、特定の業務処理やアプリケーションの処理を担当するクラスです。一般的に Service という接尾辞を付けます。
C#public class UserService
{
}
public class OrderService
{
}
public class PaymentService
{
}
ただし、何でも Service にするのは避けましょう。より具体的な役割がある場合は、その役割を名前に含めるとわかりやすくなります。
C#public class EmailSender
{
}
public class PasswordHasher
{
}
public class InvoiceGenerator
{
}
Service は便利な接尾辞ですが、クラスの責務が曖昧にならないように注意が必要です。
5-3. リポジトリクラスの命名例
リポジトリクラスは、データの取得や保存など、データアクセスを担当するクラスです。一般的に Repository という接尾辞を付けます。
C#public class UserRepository
{
}
public class OrderRepository
{
}
public class ProductRepository
{
}
対象となるデータを先頭に置き、最後に Repository を付けると自然です。
C#UserRepository
CustomerRepository
InvoiceRepository
Repository という名前を使う場合は、そのクラスが本当にデータアクセスを担当しているかを確認しましょう。単なる計算処理や画面処理に Repository を付けると、役割がわかりにくくなります。
5-4. コントローラークラスの命名例
ASP.NET Coreなどで使うコントローラークラスでは、一般的に Controller という接尾辞を付けます。
C#public class HomeController
{
}
public class UsersController
{
}
public class OrdersController
{
}
Webアプリケーションでは、URLや画面の単位に合わせた名前にすることが多いです。
C#ProductsController
CustomersController
AccountController
コントローラー名はフレームワークの規約と関係することがあるため、プロジェクトで使っているフレームワークの命名ルールにも合わせましょう。
5-5. 例外クラスの命名例
例外クラスは、一般的に Exception で終わる名前にします。
C#public class UserNotFoundException : Exception
{
}
public class InvalidOrderStateException : Exception
{
}
public class PaymentFailedException : Exception
{
}
例外名は、どのようなエラーが起きたのかが伝わる名前にします。
C#OrderNotFoundException
DuplicateEmailException
InsufficientStockException
単に CustomException や ErrorException とすると、何の例外なのかがわかりにくくなります。
5-6. DTO・ViewModel・Entityの命名例
DTOは、データ転送用のクラスです。一般的に Dto または DTO を接尾辞として使います。C#ではプロジェクトの方針によって表記が分かれることがありますが、どちらかに統一することが大切です。
C#public class UserDto
{
}
public class OrderDto
{
}
public class ProductDto
{
}
ViewModelは、画面表示用のデータを表すクラスです。
C#public class UserViewModel
{
}
public class OrderDetailViewModel
{
}
public class ProductListViewModel
{
}
Entityは、データベース上のテーブルやドメイン上の実体を表す場合に使われます。
C#public class UserEntity
{
}
public class OrderEntity
{
}
ただし、Entityについては、単に User や Order と命名するプロジェクトも多くあります。どちらが正しいというより、設計方針とプロジェクト内の統一が重要です。
5-7. Attribute・EventArgsなど特殊なクラス名の命名例
C#には、特定の用途でよく使われる接尾辞があります。
属性クラスには、一般的に Attribute を付けます。
C#public class RequiredLoginAttribute : Attribute
{
}
public class AuditLogAttribute : Attribute
{
}
イベントデータを表すクラスには、EventArgs を付けます。
C#public class OrderCreatedEventArgs : EventArgs
{
}
public class UserDeletedEventArgs : EventArgs
{
}
属性やイベント関連のクラスは、C#や.NETの慣習に合わせて命名すると、他の開発者にも意図が伝わりやすくなります。
6. クラス名で避けたいNG命名
ここでは、C#のクラス名として避けたいNG命名を具体的に見ていきます。
6-1. アンダースコアを使ったクラス名
C#のクラス名では、基本的にアンダースコアを使いません。
C#public class user_profile
{
}
public class order_service
{
}
public class customer_repository
{
}
これらはsnake_caseであり、C#のクラス名としては一般的ではありません。
C#では次のようにPascalCaseで書きます。
C#public class UserProfile
{
}
public class OrderService
{
}
public class CustomerRepository
{
}
6-2. 小文字で始まるクラス名
小文字で始まるクラス名も避けましょう。
C#public class user
{
}
public class orderService
{
}
C#では、小文字で始まる名前はローカル変数や引数に使われることが多いため、クラス名に使うと違和感があります。
C#public class User
{
}
public class OrderService
{
}
クラス名はPascalCaseにして、先頭を大文字にするのが基本です。
6-3. 意味のない略語を使ったクラス名
意味のわかりにくい略語は避けましょう。
C#public class Usr
{
}
public class Prd
{
}
public class OrdSvc
{
}
省略すると入力は少し楽になりますが、読む人にとっては理解しづらくなります。
C#public class User
{
}
public class Product
{
}
public class OrderService
{
}
クラス名は頻繁に読まれるものです。書く手間より、読むわかりやすさを優先しましょう。
6-4. 「Data」「Info」「Manager」だけの曖昧なクラス名
Data、Info、Manager のような名前だけでは、役割が曖昧です。
C#public class Data
{
}
public class Info
{
}
public class Manager
{
}
これらの名前は、何でも入れられるクラスになりやすく、時間が経つほど肥大化しやすくなります。
改善するなら、対象や責務を加えます。
C#public class UserProfile
{
}
public class ProductSummary
{
}
public class OrderManager
{
}
ただし、OrderManager のような名前も使いすぎには注意が必要です。具体的に OrderStatusUpdater や OrderCancellationService と表現できるなら、そのほうが責務が明確になります。
6-5. 数字や記号を安易に使ったクラス名
数字や記号を安易に使ったクラス名も避けたほうがよいです。
C#public class User1
{
}
public class Order2
{
}
public class Product_New
{
}
User1 や Order2 は、違いが名前からわかりません。Product_New はC#のクラス名としても不自然です。
バージョン違いや用途違いを表したい場合は、意味のある名前にしましょう。
C#public class NewUserRegistration
{
}
public class LegacyOrderImporter
{
}
public class ProductMigrationService
{
}
数字を使う場合でも、OAuth2Client や Http2Connection のように、技術名や仕様名として意味がある場合に限定するのがよいです。
6-6. プロジェクト内で表記ゆれがあるクラス名
同じ意味のクラス名で表記が揺れると、コード全体の統一感がなくなります。
C#UserDto
UserDTO
UserDataTransferObject
どれも似た意味ですが、同じプロジェクト内で混在すると迷いやすくなります。
C#OrderService
OrderManager
OrderProcessor
これらも、役割の違いが明確でないまま混在すると、どのクラスを使えばよいかわかりにくくなります。
プロジェクト内では、接尾辞や略語の表記を統一しましょう。
7. C#のクラス名で迷いやすいポイント
C#のクラス名では、初心者が迷いやすいポイントがいくつかあります。
7-1. 複数形と単数形はどちらを使うべきか
基本的に、1つの概念や1つのオブジェクトを表すクラス名は単数形にします。
C#public class User
{
}
public class Product
{
}
public class Order
{
}
コレクションそのものを表すクラスでない限り、Users や Products のような複数形は避けることが多いです。
C#public class Users
{
}
ただし、コントローラー名ではリソースの集合を表すため、UsersController や ProductsController のように複数形を使うプロジェクトもあります。
C#public class UsersController
{
}
迷った場合は、モデルクラスは単数形、コントローラーや画面単位ではプロジェクトの規約に合わせるとよいでしょう。
7-2. 略語・頭字語は大文字にするべきか
XML、HTTP、ID、DTO のような略語・頭字語は、表記に迷いやすいポイントです。
C#では、プロジェクトによって次のような表記が使われます。
C#XmlParser
HttpClient
UserId
UserDto
すべて大文字にすると、単語の区切りが読みにくくなる場合があります。
C#XMLParser
HTTPClient
UserID
UserDTO
どちらの表記を採用するかはチームやプロジェクトの方針によりますが、重要なのは一貫性です。
C#UserDto
OrderDto
ProductDto
と決めたなら、同じプロジェクト内では UserDTO と混在させないようにしましょう。
7-3. 接尾辞「Service」「Manager」「Helper」は使ってよいか
Service、Manager、Helper はよく使われる接尾辞ですが、使い方には注意が必要です。
Service は、業務処理やアプリケーション処理を担当するクラスに使われます。
C#UserService
OrderService
PaymentService
Manager は、何かを管理するクラスに使われますが、意味が広いため責務が曖昧になりやすいです。
C#UserManager
OrderManager
Helper は補助的な処理をまとめるクラスに使われますが、何でも入れられるクラスになりやすいため注意が必要です。
C#DateTimeHelper
StringHelper
より具体的にできるなら、次のような名前のほうがわかりやすいです。
C#DateTimeFormatter
PasswordHasher
EmailSender
接尾辞は使っても構いませんが、名前を見たときに責務が明確かどうかを確認しましょう。
7-4. 名前空間とクラス名はどう分けるべきか
名前空間は、クラスを分類するために使います。クラス名にすべての情報を詰め込みすぎる必要はありません。
たとえば、名前空間が次のようになっているとします。
C#namespace MyApp.Users
{
public class UserService
{
}
}
この場合、Users という分類の中に UserService があるため、役割がわかりやすくなっています。
一方で、クラス名が長くなりすぎる場合は、名前空間で整理できないか考えてみましょう。
C#namespace MyApp.Users.Registration
{
public class RegistrationService
{
}
}
このように、名前空間で文脈を補える場合は、クラス名を必要以上に長くしなくてもよい場合があります。
7-5. ファイル名とクラス名は一致させるべきか
C#では、ファイル名とクラス名が違っていてもコンパイルできる場合があります。
しかし、一般的にはファイル名と主要なクラス名は一致させるのが望ましいです。
C#// UserService.cs
public class UserService
{
}
ファイル名とクラス名が一致していると、目的のクラスを探しやすくなります。
逆に、次のように一致していないと混乱しやすくなります。
C#// Service.cs
public class UserService
{
}
特別な理由がない限り、1ファイルに1つの主要なクラスを置き、ファイル名とクラス名を一致させるとよいでしょう。
8. C#の命名規則をチームやプロジェクトで統一する方法
C#のクラス名命名規則は、個人で守るだけでなく、チームやプロジェクト全体で統一することが重要です。
8-1. 命名規則を統一するメリット
命名規則を統一すると、コードが読みやすくなります。
たとえば、クラス名はPascalCase、変数名はcamelCase、リポジトリは Repository で終わる、といったルールが決まっていれば、新しくコードを読む人も構造を理解しやすくなります。
また、命名に迷う時間を減らせます。毎回「Dto にするか DTO にするか」「Service にするか Manager にするか」で悩む必要がなくなります。
命名規則の統一は、チーム開発の効率を上げるためにも重要です。
8-2. コーディング規約としてルール化する
命名規則は、コーディング規約として明文化しておくと効果的です。
たとえば、次のようなルールを決めます。
クラス名はPascalCaseにする
クラス名は名詞または名詞句にする
例外クラスはExceptionで終わる
属性クラスはAttributeで終わる
DTOはDto表記に統一する
意味のない略語は使わない
ルールが文書化されていれば、メンバー間で判断がぶれにくくなります。
8-3. Visual StudioやEditorConfigで命名ルールを管理する
C#では、Visual StudioやEditorConfigを使って命名ルールを管理できます。
.editorconfig にルールを設定しておくと、命名規則から外れたコードを検出しやすくなります。
たとえば、型名にPascalCaseを求めるルールを設定できます。
INIdotnet_naming_rule.types_should_be_pascal_case.severity = warning
dotnet_naming_rule.types_should_be_pascal_case.symbols = types
dotnet_naming_rule.types_should_be_pascal_case.style = pascal_case_style
dotnet_naming_symbols.types.applicable_kinds = class, struct, interface, enum
dotnet_naming_style.pascal_case_style.capitalization = pascal_case
このような設定を使うことで、個人の注意だけに頼らず、ツールで命名規則を守りやすくなります。
8-4. コードレビューで確認すべき命名ポイント
コードレビューでは、クラス名について次の点を確認するとよいです。
クラス名がPascalCaseになっているか。
名詞または名詞句になっているか。
クラスの責務が名前から伝わるか。
省略しすぎていないか。
既存の命名パターンと一致しているか。Manager や Helper に処理を詰め込みすぎていないか。
命名は好みの問題に見えますが、コードの読みやすさや保守性に大きく影響します。レビューでは、動くかどうかだけでなく、名前が適切かどうかも確認しましょう。
8-5. 既存プロジェクトの命名に合わせる重要性
新しくクラスを作るときは、一般的なC#の命名規則だけでなく、既存プロジェクトのルールに合わせることも大切です。
たとえば、既存コードで UserDto、OrderDto、ProductDto と命名しているなら、新しいクラスも CustomerDto にするのが自然です。
C#public class CustomerDto
{
}
ここで突然 CustomerDTO や CustomerDataTransferObject にすると、表記ゆれが発生します。
一般的なルールよりも、プロジェクト内の一貫性が優先される場面もあります。既存コードをよく観察し、同じ考え方で名前を付けましょう。
9. 初心者向け:クラス名を決める手順
ここでは、初心者向けにクラス名を決める具体的な手順を紹介します。
9-1. クラスが表す責務を一言で説明する
まず、そのクラスが何をするためのものかを一言で説明します。
たとえば、次のように考えます。
ユーザー情報を表す
注文を保存・取得する
メールを送信する
パスワードを検証する
商品一覧画面に表示するデータを持つ
責務を一言で説明できない場合、そのクラスは複数の役割を持ちすぎている可能性があります。
9-2. 主要な名詞を抜き出す
次に、説明文から主要な名詞を抜き出します。
ユーザー情報を表す → User
注文を保存・取得する → Order
メールを送信する → Email
パスワードを検証する → Password
商品一覧画面に表示するデータを持つ → ProductList
クラス名の中心になるのは、多くの場合この主要な名詞です。
9-3. 必要に応じて役割を表す単語を加える
主要な名詞だけでは役割が伝わらない場合は、接尾辞や役割を表す単語を加えます。
User
OrderRepository
EmailSender
PasswordValidator
ProductListViewModel
たとえば、単に Order だと注文そのものを表すクラスに見えます。注文を保存・取得するクラスなら OrderRepository のほうが適切です。
単に Email だとメールデータを表すように見えます。メールを送信するクラスなら EmailSender のほうがわかりやすくなります。
9-4. PascalCaseに変換する
名前の候補が決まったら、PascalCaseに変換します。
user service → UserService
order repository → OrderRepository
password validator → PasswordValidator
product list view model → ProductListViewModel
単語の先頭を大文字にし、アンダースコアやハイフンは使いません。
C#public class UserService
{
}
public class OrderRepository
{
}
public class PasswordValidator
{
}
public class ProductListViewModel
{
}
9-5. NG例に当てはまらないか確認する
最後に、NG例に当てはまっていないか確認します。
小文字で始まっていないか。
C#userService
アンダースコアを使っていないか。
C#user_service
意味のない略語になっていないか。
C#UsrSvc
曖昧すぎる名前になっていないか。
C#Data
Manager
Info
長すぎて責務が多すぎないか。
C#UserRegistrationAndEmailNotificationAndPointGrantService
この確認をするだけでも、クラス名の品質はかなり上がります。
10. C#のクラス名命名規則に関するよくある質問
最後に、C#のクラス名命名規則についてよくある質問を解説します。
10-1. C#のクラス名は必ずPascalCaseにするべき?
基本的には、C#のクラス名はPascalCaseにするべきです。
C#では、クラス名などの型名にPascalCaseを使うのが一般的な命名規則です。PascalCaseにしなくてもコンパイルできる場合はありますが、C#らしいコードから外れて見えます。
特別な理由がない限り、クラス名はPascalCaseにしましょう。
C#public class UserService
{
}
10-2. クラス名に日本語を使ってもよい?
C#では、技術的には日本語のクラス名を使える場合があります。
C#public class ユーザー
{
}
しかし、実務では基本的に英語のクラス名を使うことが多いです。理由は、ライブラリやフレームワークとの相性、チーム開発での読みやすさ、検索性、国際的な開発環境での扱いやすさなどです。
学習目的なら日本語名で試すことはできますが、実務コードでは英語のクラス名を使うのが無難です。
C#public class User
{
}
10-3. クラス名に略語を使ってもよい?
広く理解されている略語であれば、使っても問題ない場合があります。
C#UserId
HttpClient
XmlParser
UserDto
ただし、プロジェクト内だけでしか通じない略語や、意味がわかりにくい省略は避けましょう。
C#Usr
OrdSvc
PrdMgr
略語を使う場合は、チーム内で表記を統一することが大切です。
10-4. クラス名とファイル名が違っても動く?
C#では、クラス名とファイル名が違っていても動く場合があります。
ただし、実務ではファイル名と主要なクラス名を一致させるのが一般的です。
C#// UserService.cs
public class UserService
{
}
ファイル名とクラス名を一致させることで、コードを探しやすくなり、プロジェクトの見通しもよくなります。
10-5. JavaやPythonの命名規則とC#は違う?
C#、Java、Pythonでは命名規則に違いがあります。
C#とJavaでは、クラス名にPascalCaseを使う点は似ています。
C#UserService
OrderRepository
一方、Pythonではクラス名にはCapWords、関数名や変数名にはsnake_caseを使うことが多いです。
Pythonclass UserService:
pass
user_name = "Taro"
C#では、クラス名はPascalCase、変数名や引数名はcamelCaseが一般的です。言語ごとの文化に合わせることが大切です。
10-6. 古いコードのクラス名は変更したほうがよい?
古いコードに命名規則から外れたクラス名がある場合でも、すぐに変更すべきとは限りません。
クラス名を変更すると、そのクラスを参照している多くのコードに影響する可能性があります。外部に公開しているAPIやライブラリの場合は、利用者にも影響します。
変更する場合は、次の点を確認しましょう。
変更範囲が把握できるか。
テストで影響を確認できるか。
外部利用者に影響しないか。
チームで合意できているか。
リファクタリングの目的が明確か。
新しく作るクラスは命名規則に沿って命名し、古いクラスは必要に応じて慎重に改善するのが現実的です。
まとめ
C#のクラス名命名規則では、まずPascalCaseで書くことが基本です。User、OrderService、CustomerRepository のように、各単語の先頭を大文字にして、アンダースコアを使わずに書きます。
また、クラス名には名詞または名詞句を使います。クラスは「もの」や「概念」を表すことが多いため、User、Product、Order のような名詞が自然です。処理や役割を表したい場合は、UserService、OrderRepository、PasswordValidator のように名詞句にします。
一方で、user_service、getUser、Data、UsrMgr のような名前は避けたほうがよいです。小文字で始まる名前、snake_case、意味のない略語、曖昧すぎる名前は、コードの読みやすさを下げてしまいます。
クラス名で迷ったら、次の流れで考えると決めやすくなります。
まず、クラスの責務を一言で説明します。次に、主要な名詞を抜き出します。必要に応じて Service、Repository、ViewModel、Exception などの役割を表す単語を加えます。最後にPascalCaseに整え、NG命名に当てはまらないか確認します。
C#のクラス名は、ただの文字列ではありません。コードを読む人に「このクラスは何を表しているのか」を伝える重要な情報です。命名規則を意識して、わかりやすく、保守しやすいクラス名を付けましょう。

