英語でコーディング規約を作るよう求められたとき、何を書けばいいか迷った経験はないだろうか。
コーディング規約はチームのコード品質と一貫性を維持するためのドキュメントだ。グローバルチームでは英語が基本になるが、6つのセクション構成さえ押さえれば英語でも問題なく書ける。
この記事では、コーディング規約に必要な6つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに実務で活用できる。
コーディング規約に必要な6つの構成要素
コーディング規約はチーム全員が同じスタイルでコードを書くための基準を定義するドキュメントだ。以下の6つが標準的な構成要素になる。
- 基本情報（Document Info）
- 全般ルール（General Rules）
- 命名規則（Naming Conventions）
- フォーマット・スタイル（Formatting & Style）
- コメント・ドキュメンテーション（Comments & Documentation）
- レビュー・適用ルール（Review & Enforcement）
なぜ英語で書くのか
グローバルチームではコーディング規約も英語が共通言語になる。英語で書くことで、海外のチームメンバーや外部コントリビューターも同じ基準でコードを書ける。
「読めば誰でも同じコードが書ける」ことが、コーディング規約の最大の目的だ。
コーディング規約とリンター設定の使い分け
コーディング規約は「なぜそのルールが必要か」の背景と例外処理まで含めた人間向けのドキュメントだ。一方、リンター設定（ESLint・Pylint等）は自動検出できるルールを機械に委ねる。両方を整備することで、コード品質の維持が体系化される。
コードレビューの英語フレーズは英語コードレビューの進め方でも確認してほしい。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
基本情報
| 項目 | 内容 |
|---|---|
| プロジェクト名 | （例：〇〇システム開発プロジェクト） |
| 対象言語 | （例：TypeScript / Python / Go） |
| バージョン | v1.0 |
| 作成日 | YYYY-MM-DD |
| 作成者 | （名前・役職） |
| 最終更新日 | YYYY-MM-DD |
| ステータス | Draft / In Review / Approved |
全般ルール
| # | ルール | 理由 |
|---|---|---|
| 1 | 1ファイル1責務を原則とする | 単一責任原則に従い、変更の影響範囲を限定するため |
| 2 | 1関数は50行以内を目安にする | 可読性と単体テストのしやすさを確保するため |
| 3 | マジックナンバーは定数に定義する | コードの意図を明確にし、変更を一元管理するため |
| 4 | エラーは必ず明示的にハンドリングする | サイレントエラーによる予期せぬ動作を防ぐため |
| 5 | 不要なコメントアウトはコミット前に削除する | コードの可読性を保ち、混乱を避けるため |
命名規則
| 対象 | 規則 | 例 |
|---|---|---|
| 変数名 | キャメルケース（camelCase） | userId, orderCount |
| 定数名 | 大文字スネークケース（UPPER_SNAKE_CASE） | MAX_RETRY_COUNT, API_BASE_URL |
| 関数名 | 動詞で始めるキャメルケース | getUserById(), calculateTotal() |
| クラス名 | パスカルケース（PascalCase） | UserService, OrderRepository |
| ファイル名 | ケバブケース（kebab-case） | user-service.ts, order-utils.py |
| インターフェース名 | 先頭にIをつけない（TypeScriptの場合） | UserRepository（IUserRepositoryは不可） |
フォーマット・スタイル
| 項目 | 設定値 | 備考 |
|---|---|---|
| インデント | スペース2つ（または4つ） | タブ禁止。プロジェクトで統一すること |
| 1行の最大文字数 | 120文字 | 長い場合は適切に改行する |
| 文字コード | UTF-8 | BOMなし |
| 改行コード | LF（Unix形式） | CRLFは使用禁止 |
| 末尾の空白 | 禁止 | エディタの自動削除設定を推奨 |
| import文 | グループ分けして並べる | 外部ライブラリ→内部モジュール→型定義の順 |
コメント・ドキュメンテーション
| 対象 | ルール |
|---|---|
| 関数・メソッド | JSDoc / docstringで引数・戻り値・例外を記述する |
| 複雑なロジック | 「何をしているか」ではなく「なぜそうしているか」をコメントする |
| TODO / FIXME | TODO: [担当者名] 内容 の形式で記述する |
| 公開API | すべてのpublic関数にドキュメントを必須とする |
| 自明なコード | コメント不要。コードが自己説明的になるよう命名を工夫する |
レビュー・適用ルール
| 項目 | 内容 |
|---|---|
| 適用開始日 | YYYY-MM-DD |
| 適用対象 | すべての新規コード。既存コードはリファクタリング時に随時適用 |
| 自動チェック | ESLint / Pylint をCIに組み込み、PRマージ前にチェックを必須とする |
| コードレビュー | レビュアーはこの規約への準拠を確認する。違反はコメントで指摘する |
| 例外処理 | 業務上やむを得ない場合は、該当箇所に理由をコメントし、TLの承認を得る |
| 規約の更新 | チームの合意のうえ更新し、変更履歴に記録する |
英語版テンプレート（コピペOK）
Document Info
| Field | Value |
|---|---|
| Project Name | (e.g., [System Name] Development Project) |
| Target Language | (e.g., TypeScript / Python / Go) |
| Version | v1.0 |
| Created Date | YYYY-MM-DD |
| Author | (Name / Role) |
| Last Updated | YYYY-MM-DD |
| Status | Draft / In Review / Approved |
General Rules
| # | Rule | Reason |
|---|---|---|
| 1 | Each file should have a single responsibility. | Following the Single Responsibility Principle to limit the scope of changes. |
| 2 | Aim to keep functions under 50 lines. | To ensure readability and ease of unit testing. |
| 3 | Define magic numbers as named constants. | To clarify intent and centralize changes. |
| 4 | Always handle errors explicitly. | To prevent unexpected behavior from silent errors. |
| 5 | Remove commented-out code before committing. | To maintain code readability and avoid confusion. |
Naming Conventions
| Target | Convention | Example |
|---|---|---|
| Variables | camelCase | userId, orderCount |
| Constants | UPPER_SNAKE_CASE | MAX_RETRY_COUNT, API_BASE_URL |
| Functions | camelCase starting with a verb | getUserById(), calculateTotal() |
| Classes | PascalCase | UserService, OrderRepository |
| Files | kebab-case | user-service.ts, order-utils.py |
| Interfaces | No I prefix (TypeScript) | UserRepository (not IUserRepository) |
Formatting & Style
| Item | Setting | Notes |
|---|---|---|
| Indentation | 2 spaces (or 4) | No tabs. Keep consistent across the project. |
| Max line length | 120 characters | Break lines appropriately if exceeded. |
| Encoding | UTF-8 | No BOM. |
| Line endings | LF (Unix-style) | CRLF is not allowed. |
| Trailing whitespace | Not allowed | Configure your editor to auto-remove. |
| Import order | Group and sort imports | External libraries → internal modules → type definitions |
Comments & Documentation
| Target | Rule |
|---|---|
| Functions / Methods | Use JSDoc / docstrings to describe parameters, return values, and exceptions. |
| Complex logic | Comment on why, not what. |
| TODO / FIXME | Use format: TODO: [Author Name] Description |
| Public APIs | Documentation is required for all public functions. |
| Self-explanatory code | No comment needed. Focus on clear naming instead. |
Review & Enforcement
| Item | Details |
|---|---|
| Effective Date | YYYY-MM-DD |
| Scope | All new code. Apply to existing code during refactoring. |
| Automated Checks | ESLint / Pylint integrated in CI. Compliance check required before PR merge. |
| Code Review | Reviewers must verify compliance with this standard. Flag violations in comments. |
| Exceptions | If a deviation is necessary, add a comment explaining the reason and get TL approval. |
| Updates | Update by team consensus and record changes in the change log. |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいセクションを解説する。
命名規則の書き方
命名規則は「なぜその規則なのか」の背景も添えると、新メンバーが自律的に判断できるようになる。
| 日本語 | 英語 |
|---|---|
| 意図が伝わる名前をつける | Use names that clearly communicate intent. |
| 省略形は避け、フルネームで書く | Avoid abbreviations; use full words. |
| 否定形の変数名は避ける | Avoid negated variable names (e.g., isNotValid). |
| 複数形でコレクションを表現する | Use plural nouns for collections (e.g., users, orders). |
| 動詞で始まる関数名にする | Start function names with a verb (e.g., get, create, update). |
コードレビューでの指摘フレーズ
コーディング規約違反をレビューで指摘するときのフレーズをまとめた。
| 日本語 | 英語 |
|---|---|
| 命名規則に従っていません | This doesn’t follow our naming convention. |
| マジックナンバーを定数に切り出してください | Please extract this magic number into a named constant. |
| 関数が長すぎます。分割を検討してください | This function is too long. Consider splitting it. |
| コメントは「なぜ」を説明してください | The comment should explain why, not what. |
| このコードには単体テストが必要です | This code needs a unit test. |
英語でのコードレビューへの返し方は英語コードレビューへの返し方でも確認してほしい。
コーディング規約でよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
コード品質・スタイル用語
| 日本語 | 英語 |
|---|---|
| 命名規則 | Naming convention |
| コーディングスタイル | Coding style |
| リンター | Linter |
| コードフォーマッター | Code formatter |
| 静的解析 | Static analysis |
| 技術的負債 | Technical debt |
| リファクタリング | Refactoring |
| コードの可読性 | Code readability |
レビュー・承認フレーズ
| 日本語 | 英語 |
|---|---|
| この規約に準拠しています | This is compliant with our coding standards. |
| 規約の例外として承認します | Approved as an exception to the coding standards. |
| 規約を更新する必要があります | The coding standards need to be updated. |
| チームで合意を取りましょう | Let’s reach a consensus as a team. |
| 自動化できるルールはリンターに委ねましょう | Let’s delegate automatable rules to the linter. |
英語READMEのテンプレートは、英語READMEの書き方でも紹介しているので参考にしてほしい。
まとめ：英語コーディング規約は6つのセクションで完成する
英語コーディング規約に必要な構成要素を整理した。
- 全般ルールで「なぜそのルールが必要か」の背景を明記する
- 命名規則で「変数・関数・クラスの命名パターン」を統一する
- フォーマット設定で「インデント・行長・改行コード」を標準化する
- レビュー・適用ルールで「いつから・どこに・どう適用するか」を定義する
テンプレートをコピーして、チームの技術スタックに合わせてルールを追加・削除してほしい。特に命名規則と自動チェックの2点を早期に整備することで、コードレビューの議論が格段にスムーズになる。
コメント