コーディング規約とは、複数人で開発を進める際にソースコードの見た目や書き方を統一し、可読性や保守性を高めるためのルール集です。たとえば、変数や関数の名前付けルール、インデント幅、波かっこの配置、コメントの書き方といった細かな取り決めを文書化しておくことで、誰が書いても同じようなスタイルでコードを書けるようになります。
具体的には、関数名は小文字のキャメルケース(たとえば calculateTotalPrice)とし、クラス名は先頭を大文字にしたパスカルケース(OrderManager)で統一するといった命名規則があります。
JavaScript の場合、波かっこは同じ行の末尾に置くスタイルが多く、たとえば
というように、一貫して書きます。もし開きかっこを次の行に書くスタイルを混在させると、コードを追うときに無駄なスクロールや目の移動が増えてしまい、可読性が落ちる原因になります。
Python ではインデント幅をスペース４つに統一し、関数名や変数名にはスネークケース(calculate_total_price)を使うのが一般的です。また、モジュールの先頭には必ずドキュメンテーション文字列(docstring)を配置するように規約で定めることもあります。
たとえば
と書くことで、関数の役割や引数の型・構造が一目でわかるようになります。
こうしたルールをプロジェクトごとにまとめたドキュメントがコーディング規約であり、Lint(静的解析)ツールと組み合わせることで自動的に規約違反を検出・修正することも可能です。結果としてチームメンバー間の理解負荷が減り、新しく参加したエンジニアでもすぐに既存コードに合わせた形で実装が行えるようになるのが大きなメリットとなります。
Coding standards are a documented set of rules that a development team follows to ensure source code looks and behaves in a consistent way. By stipulating details such as how to name variables and functions, how many spaces to use for indentation, where to place curly braces and how to format comments, everyone on the team writes in the same style. This consistency makes code easier to read and maintain, reduces the mental overhead when switching between different parts of the codebase, and helps new team members ramp up more quickly.
For naming conventions, it’s common to use lower-camel-case for functions—so you might name a function calculateTotalPrice—and PascalCase for classes, for example OrderManager. By sticking to these rules, you never have to wonder whether a method should be called calculate_total_price, CalculateTotalPrice, or something else entirely.
In JavaScript, many teams place the opening curly brace on the same line as the statement. For example:
If someone were to mix in a style where the brace appears on the next line, you’d end up scrolling more or shifting your eyes up and down, which breaks the flow when you’re tracing logic.
In Python, the convention is to use four spaces per indent level and to name functions and variables in snake_case, such as calculate_total_price. It’s also common to require a docstring at the top of each module and each public function or class. For example:
That docstring makes it immediately clear what the function does and what shape its inputs take.
All of these rules live in a project’s coding-standards document. When paired with a linter or other static-analysis tool, violations can be flagged or even automatically corrected. The end result is that team members spend less time guessing at style rules, review code more quickly, and can onboard new engineers with minimal friction.
株式会社ASAP
及川知也
