命名規則は採用するスタイルガイドやプロジェクトの規約によって異なり、同じ「定数」でもPythonとJavaはMAX_RETRY、C#はMaxRetry、Google流のC++はkMaxRetryと書き方が分かれます。Pythonのファイル名は小文字のスネークケース(my_module.py)が正解で、ハイフン入りのmy-module.pyはimport文で読み込めません。この記事では、キャメルケース・スネークケースなどの書き方の違いと、Python・Java・JavaScript・C++・C#・Rubyの変数・関数・クラス・定数・ファイル名の規則を整理します。言語ごとの落とし穴は、手元で実際に動かした結果(2026年9月時点)とあわせて示します。
まとめ:6言語の命名規則早見表
| 言語 | 変数・関数 | クラス・型 | 定数 | ファイル名 |
|---|---|---|---|---|
| Python | snake_case | PascalCase | UPPER_SNAKE | snake_case.py |
| Java | camelCase | PascalCase | UPPER_SNAKE | クラス名.java |
| JavaScript・TypeScript | camelCase | PascalCase | UPPER_SNAKE | 小文字(JSは _ か -、TSは _) |
| C# | ローカル変数 camelCase/メソッド PascalCase | PascalCase | PascalCase | 型名.cs(慣習) |
| C++(Google流) | 変数 snake_case/関数 PascalCase | PascalCase | kPascalCase | 小文字(_ か -) |
| Ruby | snake_case | PascalCase | UPPER_SNAKE | snake_case.rb |
- クラス・型のPascalCaseは6言語で共通です。差が出るのは変数・関数・定数・ファイル名です。
- Pythonのモジュール名にハイフンがあると、通常の
import文では読み込めません。 - Javaは
publicクラスとファイル名が一致しないとコンパイルエラーになります。 - JavaScriptでは、ファイル名とインポート指定の大文字小文字が食い違うと、大文字小文字を区別するファイルシステム上で読み込みに失敗します。ファイル名は小文字にそろえてください。
- 略語(HTTP・XML・ID)の書き方はガイドによって分かれます。Python・Rubyは
HTTPServerError、JavaとC#はXmlHttpRequestです。 - 規約は人の注意ではなく、リンター(Ruff・ESLint・RuboCopなど)で機械的にチェックします。
キャメルケース・スネークケース・ケバブケースの違い
命名規則でいう「ケース」は、複数の英単語を1つの名前につなぐときの区切り方です。名前にスペースを入れられないので、大文字で区切るか記号で区切るかを決めます。
| 名称 | 別名 | 例 | 主な用途 |
|---|---|---|---|
| キャメルケース | lowerCamelCase | userName | Java・JS・C#の変数 |
| パスカルケース | アッパーキャメルケース | UserName | 各言語のクラス・型 |
| スネークケース | snake_case | user_name | Python・Rubyの変数・関数 |
| アッパースネークケース | SCREAMING_SNAKE_CASE | USER_NAME | 定数 |
| ケバブケース | kebab-case | user-name | URL・CSSクラス・ファイル名 |
キャメルケースは、途中の大文字がラクダ(camel)のこぶに見えることからの呼び名です。先頭を小文字にするuserNameだけを指すことが多く、先頭も大文字にするUserNameはパスカルケース(アッパーキャメルケース)と呼び分けます。PEP 8ではこの形を「CapWords」と呼んでいます。
使い分けは好みではなく、その言語で広く採用されている規約で決まります。PythonでcamelCaseを使っても動きはしますが、標準ライブラリやほかのライブラリと混ざったときに1ファイルの中で書き方が揃わなくなります。ケバブケースだけは事情が違い、ほとんどの言語で-が引き算の演算子になるため変数名には使えません。使いどころはURL、CSSのクラス名、HTMLのカスタム要素名、ファイル名です。
Pythonの命名規則とファイル名(モジュール名)
変数・関数・クラス・定数:PEP 8の規則
Pythonの命名は公式スタイルガイドPEP 8に従います(原文はPEP 8のNaming Conventions)。関数名は「lowercase, with words separated by underscores」、変数名も関数名と同じ規則で、クラス名は「CapWords」、定数は「all capital letters with underscores separating words」と定められています。
MAX_RETRY = 3 # 定数:モジュールの先頭で定義
class OrderService: # クラス:PascalCase(CapWords)
def fetch_order(self, order_id): # メソッド・引数:snake_case
retry_count = 0 # 変数:snake_case
return retry_count
class PaymentError(Exception): # 例外:末尾に Error
pass
PEP 8は細かい規則も定めています。実際にエラーを表す例外クラスには接尾辞「Error」を付けます。l(小文字のエル)・O(大文字のオー)・I(大文字のアイ)は、数字の1や0と見分けにくいため1文字の変数名に使いません。予約語とぶつかったときはclass_のように末尾へ_を付けます。mixedCase(camelCase)は、threading.pyのように既にその書き方が主流になっている箇所で、後方互換のためにだけ認められています。
ファイル名・パッケージ名:小文字とアンダースコアの使い分け
PEP 8はモジュール名について「Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability.」と定めています。パッケージ名(ディレクトリ名)も小文字の短い名前ですが、こちらは「the use of underscores is discouraged」とされ、アンダースコアの使用も推奨されません。Pythonではファイル名がそのままモジュール名になり、import文の識別子になるためです。
Python 3.14.6で、内容をX = 1としたmy-module.pyを作成し、そのファイルのあるディレクトリで実行した結果です。
$ python3 -c 'import my-module'
import my-module
^
SyntaxError: invalid syntax
$ python3 -c 'import importlib; m = importlib.import_module("my-module"); print(m.X)'
1
import my-moduleは、モジュール名を指定する位置にハイフンを書けないため、構文エラーになります。importlib.import_module()に文字列で渡せば読み込めますが、動的に読み込む用途で使われるAPIであり、通常のモジュール名にハイフンを採用する理由にはなりません。ファイル名はmy_module.pyにしてください。先頭を数字にした1st_step.pyや、class.pyのような予約語と同じ名前も、同じ理由でimport文では読み込めません。
Pythonファイル名と標準ライブラリの衝突
練習用にrandom.pyやjson.pyを作ると、自分のファイルが標準ライブラリより先に読み込まれ、標準ライブラリが使えなくなります。import randomしてrandom.randint()を呼ぶだけのrandom.pyを実行すると、Pythonのバージョンによってエラーの出方が違いました。
# Python 3.12.13
AttributeError: partially initialized module 'random' has no attribute 'randint' (most likely due to a circular import)
# Python 3.13.14 / 3.14.6
AttributeError: module 'random' has no attribute 'randint' (consider renaming '/private/tmp/n2339py/random.py' since it has the same name as the standard library module named 'random' and prevents importing that standard library module)
3.12までは「循環インポート」と表示されるため、ファイル名が原因だと気づきにくくなっています。3.13以降は改名を促すメッセージに変わりました。test.py・email.py・csv.pyなど、よく使う名前ほど標準ライブラリと重なりやすいので、csv_export.pyのように用途を足して名前をずらします。
先頭・末尾のアンダースコアの意味
_name(先頭に1つ):内部用の目印です。__all__が未定義の場合、from mod import *の対象から外れます。PUBLICと_privateを持つモジュールで実測すると、取り込まれたのはPUBLICだけでした。__name(先頭に2つ):クラス名を付けた名前に変換されます(name mangling)。PEP 8は、サブクラスとの名前の衝突を避けるときに限って使うよう求めています。__name__(前後に2つ):言語が予約している特殊名です。自分で新しく作りません。name_(末尾に1つ):予約語や組み込み名との衝突を避けるときに使います(予約語にはclass_、組み込み名にはtype_)。
Javaの命名規則:publicクラス名とファイル名の一致
Javaの命名は、Oracle(旧Sun)のCode Conventionsではなく、現在も更新されているGoogle Java Style Guideを基準にすると迷いません。Code Conventionsは「Revised April 20, 1999」のまま、Oracle自身が「This page is not being actively maintained」と注記したアーカイブ扱いのページです。Google Java Style Guideはパッケージ名を「only lowercase letters and digits (no underscores)」とし、com.example.deepspaceを正、deepSpaceやdeep_spaceを誤りとして例示しています。クラス名はUpperCamelCase、メソッド名・変数名はlowerCamelCaseです。
定数の定義は厳密で、UPPER_SNAKE_CASEにできるのは「static final fields whose contents are deeply immutable」、つまり中身まで変更できないstatic finalフィールドだけです。static finalでも、要素を追加できるListを持つフィールドは定数扱いにならず、lowerCamelCaseで書きます。
package com.example.orderapi; // パッケージ:小文字のみ
public class OrderService { // クラス:PascalCase
public static class Order {} // 戻り値に使う型
static final int MAX_RETRY = 3; // 定数:UPPER_SNAKE_CASE
private int retryCount; // フィールド:camelCase
public Order findOrderById(long orderId) { // メソッド:camelCase
return null;
}
}
ファイル名は、Google Java Style Guideで「the case-sensitive name of the top-level class」に.javaを付けたものと決められています。ただしこれはガイド上の規則で、コンパイラが強制するのはpublicクラスの場合だけです。public class OrderServiceをorderservice.javaに保存してjavac 25.0.4.1でコンパイルすると、次のエラーになりました。
orderservice.java:1: error: class OrderService is public, should be declared in a file named OrderService.java
publicを付けないclass helperをFoo.javaに書いた場合はエラーにならず、helper.classが生成されます。コンパイルは通っても、ファイル名からクラスを探せなくなるので、1ファイル1クラスでファイル名とクラス名を揃えます。Javaの文字列比較やStreamなど、命名以外の書き方はJavaのコード例で学ぶ書き方の基本で扱っています。
JavaScript・TypeScriptの命名規則とファイル名
変数・定数・クラスの書き分け
この記事のJavaScriptの命名例はGoogle JavaScript Style Guideを基準にします。ただし、同ガイドは更新を終了しており、GoogleはTypeScriptとそのガイドへの移行を推奨しています。ローカル変数・引数・関数はlowerCamelCase、クラスはUpperCamelCaseです。定数のCONSTANT_CASEは深く不変なモジュール内のconst宣言や@const付き静的プロパティに使い、ガイドは「Constants in function scopes are still named in lowerCamelCase」と明記しています。constで宣言した変数を全部大文字にするわけではありません。
const MAX_RETRY = 3; // モジュール最上位の定数:CONSTANT_CASE
export class OrderClient { // クラス:PascalCase
async fetchOrder(orderId) { // メソッド・引数:camelCase
const retryCount = 0; // 関数内の const は camelCase
return retryCount;
}
}
Google TypeScript Style Guideも、変数・関数・プロパティはlowerCamelCase、「global constant values, including enum values」はCONSTANT_CASEとしています。ファイル名はGoogle JavaScript Style Guideが「all lowercase and may include underscores (_) or dashes (-)」と定める一方、Google TypeScript Style Guideは「files are snake_case」と、同じGoogleでも言語によって区切り記号が違います。どちらの場合も、すべて小文字にする点は共通です。
ファイル名の大文字小文字:インポート指定との不一致によるエラー
JavaScriptのファイル名で事故が多いのは、区切り記号より大文字小文字の食い違いです。macOSで一般的な、大文字小文字を区別しない形式のAPFSでは、helper.mjsというファイルをimport文で./Helper.mjsと書いても読み込めてしまいます。Node.js v26.5.0で同じ2ファイルを、大文字小文字を区別するボリューム(Linuxのext4と同じ扱い)に置いて実行した結果です。
# macOS 標準ボリューム
$ node m.mjs
loaded 2
# 大文字小文字を区別するボリューム
$ node m.mjs
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Volumes/cs2339/Helper.mjs' imported from /Volumes/cs2339/m.mjs
手元で動いたコードが、Linuxで動くCIや本番サーバーで初めて落ちます。TypeScriptはこの食い違いをコンパイル時に検出します。forceConsistentCasingInFileNamesを指定しなくても、TypeScript 7.0.2では次のエラーになりました。
main.ts(1,19): error TS1261: Already included file name '/tmp/n2339ts/UserService.ts' differs from file name '/tmp/n2339ts/userService.ts' only in casing.
このオプションをfalseにするとエラーは消えますが、問題が解決するわけではありません。なお、Python 3.14.6は大文字小文字を区別しないmacOS上でも、Utils2.pyをimport utils2で読み込もうとするとModuleNotFoundErrorを出しました。通常はファイル名の大文字小文字をインポート時に照合するためです。ただし、macOSで環境変数PYTHONCASEOKを設定すると照合が緩和されるため、Pythonでも表記を一致させてください。JavaScriptのファイル名はすべて小文字にするのが確実です。ファイル名の規則はESLintのプラグインで強制できます(ESLintの設定方法)。
C#の命名規則:定数名のPascalCase表記
C#はMicrosoft Learnの「C# identifier naming rules and conventions」が基準です。ほかの言語と大きく違うのは定数で、「use PascalCase for constant names, both fields and local constants」とされ、MAX_RETRYではなくMaxRetryと書きます。
| 対象 | 規則 | 例 |
|---|---|---|
| クラス・メソッド・public メンバー | PascalCase | OrderService、FindOrder |
| 定数(フィールド・ローカル) | PascalCase | MaxRetry |
| ローカル変数・引数 | camelCase | retryCount |
| private・internal 非定数インスタンスフィールド | _camelCase | _workerQueue |
| private・internal 非定数staticフィールド | s_camelCase | s_workerQueue |
| インターフェース | I + PascalCase | IWorkerQueue |
s_接頭辞については、Microsoft Learn自身が「isn’t the default Visual Studio behavior, nor part of the Framework design guidelines」と注記しています。.NETランタイムチームのスタイルであり、全プロジェクト共通の規則ではありません。列挙型はフラグでない場合は単数形、フラグの場合は複数形の名詞にし、属性クラスにはAttributeを末尾に付けます。これらの規則はチームごとに.editorconfigへ書いておくと、エディターやIDEが違っても同じ規則で検査できます(Riderの.editorconfigと設定レイヤーの優先順位)。
C++の命名規則:Google C++ Style Guideの表記基準
C++には言語公式の命名規約がなく、プロジェクトごとの規約が優先されます。標準ライブラリはstd::vectorやpush_backのようにsnake_caseです。一方、広く参照されるGoogle C++ Style Guideは次の規則です。
- 型(クラス・構造体・列挙型・型エイリアス):PascalCase(
MyExcitingClass) - 変数・引数:snake_case(
table_name)。クラスのデータメンバーは末尾に_(table_name_)。ただし、staticな定数メンバーは定数の命名規則に従います - 通常の関数:PascalCase(
AddTableEntry())。アクセサー・ミューテーターはcount()やset_count()のようなsnake_caseも可 - 定数(プログラムの実行中に値が変わらない
const・constexpr):kで始める(kDaysInAWeek)。この規則は静的記憶域期間の定数に適用し、自動変数などでは任意 - 列挙子:マクロ風の
ENUM_NAMEではなくkEnumName - マクロ:全大文字にアンダースコアを付け、プロジェクト固有の接頭辞を付ける
- ファイル名:小文字で、
_か-を含めてよい。統一された慣習がなければ_を選ぶ(my_useful_class.cc)
C++には、書き方の好みではなく言語規格で使えない名前があります。規格の[lex.name]は「Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter」を処理系の予約としています。メンバー変数の目印に_Countやm__countを使うと予約名に当たります。規格上は使ってはいけない名前ですが、コンパイラには警告する義務がなく(no diagnostic required)、エラーにならないまま残ります。メンバーの目印は、Google流の末尾_にするのが安全です。
Rubyの命名規則:ファイル名とクラス名の対応
RubyはRuboCopのRuby Style Guideが事実上の標準です。メソッド・変数はsnake_case、クラス・モジュールはCamelCase、定数(クラス・モジュール以外)は「SCREAMING_SNAKE_CASE」です。ファイル名もsnake_caseで、同ガイドは「Name the file name as the class/module, but replacing CapitalCase with snake_case」と、ファイル名とクラス名を対応させるよう求めています。真偽値を返すメソッドはempty?のように末尾へ?を付け、is_のような接頭辞は避けます。
Rubyでは、大文字で始まる名前は文法上すべて定数になります。Ruby 4.0.6での挙動は次のとおりです。
class user_account # 小文字のクラス名
# => class/module name must be CONSTANT(構文エラー)
MAX_RETRY = 3
MAX_RETRY = 5
# => warning: already initialized constant MAX_RETRY
# 警告は出るが再代入は成功し、値は 5 になる
Rubyの定数は再代入を止められないため、定数名はあくまで「変更しない」という目印です。コードの規約違反はRuboCopのNaming系のルールで検出できます。
略語(HTTP・XML・ID)の大文字表記:言語別ガイドの違い
ケースの規則が決まっていても、名前に略語が入ると、表記は参照するガイドによって分かれます。別の言語で使っていた表記をそのまま持ち込むと、採用した規約に合わない場合があります。
| 基準 | 推奨 | 非推奨 |
|---|---|---|
| Python(PEP 8) | HTTPServerError | HttpServerError |
| Ruby(Ruby Style Guide) | SomeXML | SomeXml |
| Java(Google Java Style) | XmlHttpRequest、newCustomerId | XMLHTTPRequest、newCustomerID |
| C#(.NET設計ガイドライン) | HtmlTag、IOStream | HTMLTag |
PEP 8は「capitalize all the letters of the acronym」と略語を全部大文字にする一方、Google Java Style Guideは略語も含めていったん全部小文字にしてから単語の先頭だけを大文字にする手順を示しています。.NETは中間で、IOのような2文字の略語だけを全部大文字にし、3文字以上はHtmlのように先頭だけを大文字にします。
Rubyではさらに、スタイルガイドとRailsの自動読み込み(Zeitwerk)が衝突します。Ruby Style Guideの推奨どおりhtml_parser.rbにclass HTMLParserを書き、Zeitwerk 2.8.3で読み込むと次のエラーになりました。
Zeitwerk::NameError: expected file lib/html_parser.rb to define constant HtmlParser, but didn't
Zeitwerkはファイル名html_parserからHtmlParserという定数名を機械的に作るためです。HTMLParserを使うなら、loader.inflector.inflect("html_parser" => "HTMLParser")のように読み替えの設定を追加します(Railsガイドがいちばん簡単な方法として挙げるのは、ActiveSupport::Inflector.inflectionsでinflect.acronym "HTML"と略語を登録する方法です。仕組みはZeitwerkの解説を参照)。設定を増やしたくなければHtmlParserで書くほうが手間がかかりません。既存のコードベースに合わせるのが最優先で、新規プロジェクトでは参照するスタイルガイドを決め、フレームワークの制約や公開APIとの互換性に必要な例外をチームの規約に記録します。
命名規則をリンターで強制する方法
命名規則はレビューで指摘するより、リンターで機械的にチェックするほうが確実です。言語ごとの代表的なルールは次のとおりです。
| 言語 | ツール | ルール |
|---|---|---|
| Python | Ruff | N801〜N818、N999 |
| JavaScript・TypeScript | typescript-eslint | naming-convention |
| JavaScript(ファイル名) | eslint-plugin-unicorn | filename-case(既定はkebabCase) |
| Java | Checkstyle | TypeName、ConstantName など |
| C# | .editorconfig + Roslyn | IDE1006 |
| C++ | clang-tidy | readability-identifier-naming |
| Ruby | RuboCop | Naming/FileName など |
Ruff 0.16.9で、規約違反をまとめたpkg/Bad-Name.pyを--select N付きでチェックすると、6件すべてが検出されました。pkgディレクトリには空の__init__.pyを置き、Bad-Name.pyの中身は次のとおりです。
class httpClient: pass
def GetData(): pass
maxRetry = 3
def f():
myVar = 1
return myVar
class MyErr(Exception): pass
$ ruff check --select N --output-format concise .
pkg/Bad-Name.py:1:1: N999 Invalid module name: 'Bad-Name'
pkg/Bad-Name.py:1:7: N801 Class name `httpClient` should use CapWords convention
pkg/Bad-Name.py:2:5: N802 Function name `GetData` should be lowercase
pkg/Bad-Name.py:3:1: N816 Variable `maxRetry` in global scope should not be mixedCase
pkg/Bad-Name.py:5:5: N806 Variable `myVar` in function should be lowercase
pkg/Bad-Name.py:7:7: N818 Exception name `MyErr` should be named with an Error suffix
Found 6 errors.
ファイル名を検査するN999は、__init__.pyのあるパッケージや、namespace-packagesで指定したディレクトリ内のファイルが対象です。同じディレクトリの最上位に置いたmy-module.pyは報告されませんでした。単体のスクリプトはファイル名の検査から漏れるので、ファイル名はリンターに頼らず作成時に揃えます。
既存のコードベースに後からリンターを入れる場合、全ルールを一度に有効にすると修正が数百件になることがあります。まず新規・変更ファイルだけに適用し、既存コードの一括修正は別のプルリクエストに分けてください。PEP 8自身も「do not break backwards compatibility just to comply with this PEP!」と書いており、公開済みの関数名やAPIの名前を規約のためだけに変更する必要はありません。
よくある質問
変数名に日本語やローマ字は使えますか?
Python 3・Java・JavaScriptなどは識別子にUnicodeを使えるので、合計 = 1のような日本語の変数名も動きます(Python 3.14.6で実行を確認)。ただしPEP 8は標準ライブラリの識別子をASCIIに限っており、チーム開発では英語で書くのが一般的です。ローマ字は読み方が人によって揺れるので避けます。英単語の選び方はプログラミングの命名規則を英語で書く方法で解説しています。
enum(列挙型)のメンバー名はどう書きますか?
言語ごとに異なります。Pythonは公式のenum HOWTOが「strongly recommend using UPPER_CASE names for members」としています。TypeScript(Googleスタイル)とJavaはCONSTANT_CASE、C#はPascalCase、Google流のC++はkEnumNameです。C#の列挙型の名前自体は、フラグでなければ単数形にします。
ケバブケースはどこで使いますか?
変数名には使えないので、URL・CSSのクラス名・ファイル名・パッケージ名で使います。HTMLのカスタム要素は、HTML Standardの規定で名前にハイフンを含める必要があります(<user-card>)。npmのパッケージ名は、新規パッケージでは大文字を使えません。単語の区切りにはハイフンを使えますが、ハイフンは必須ではありません。
プロジェクトの既存コードが規約と違うときはどちらに合わせますか?
既存コードに合わせます。PEP 8は「Consistency within a project is more important. Consistency within one module or function is the most important.」と、規約との一致よりプロジェクト内の一貫性を優先しています。規約へ移行するなら、リンターのルールを段階的に有効にしていきます。
Laravel・PHPの命名規則はどうなっていますか?
PHPはPSR-1でクラス名がStudlyCaps、メソッド名がcamelCaseと定められています。LaravelではさらにEloquentがモデル名とテーブル名の対応(Userとusers)を規約として持っています。詳細はLaravelの命名規則一覧にまとめています。