最初は
いや,
えっ,
そんなこと,
コーディングスタイルとは
プログラムのアルゴリズムやロジックとは無関係に,
- インデント
(字下げ) の幅 - 半角スペース2文字分でインデントする
- 半角スペース4文字分でインデントする
- 半角スペース8文字分でインデントする
- インデントのしかた
- タブ文字でインデントする
(ハードタブ) - インデントの幅に相当する数の半角スペースで行う
(ソフトタブ)
- タブ文字でインデントする
- スペースの空けかた
function ( arg1, arg2 )
のようにスペースを空けるfunction(arg1,arg2)
のようにスペースを詰める
- 複数単語が連なる識別子
(注1) の書きかた - 小文字の単語とアンダースコアで
variable_
のように書くname (注2) - 先頭の単語はすべて小文字,
2つ目以降の単語は先頭文字を大文字にして variableName
のように書く(注3) - 単語の先頭文字を大文字にして
VariableName
のように書く(注4)
- 小文字の単語とアンダースコアで
- 改行の位置
- 関数の宣言では型名のあとで改行するのか,
しないのか - 関数の宣言やif文では波括弧の前で改行するのか,
しないのか
- 関数の宣言では型名のあとで改行するのか,
このような違いはコーディングスタイルと言われます。コーディングスタイルはコーディング規約の一部としてプロジェクトごとに定められている場合があり,
- 注1)
- 変数名,
関数名, クラス名, モジュール名などのことです。 - 注2)
- 蛇の体がうねる様子になぞらえて
「スネークケース」 と呼ばれます。 - 注3)
- ラクダの背中のこぶになぞらえて
「キャメルケース」 と呼ばれます。 - 注4)
- キャメルケースの変形として
「アッパー (大文字の) キャメルケース」 と呼ばれます。あるいは, Pascal という言語で初めて採用された書きかたであることから 「パスカルケース」 とも呼ばれます。
スタイルがバラバラのコードは読みづらい
次のような理由から,
- 複数人で開発する際に,
コーディング規約が決まっていなかった - 別のプロジェクトからコードを引用した
- その場しのぎで適当に直したものがそのまま残った
- 前任者からの引き継ぎが不十分だった
文法エラーになるような致命的な間違いと異なり,
リスト1 スタイルが統一されていないコード
// インデント幅がスペース2 つ
// 関数名がスネークケース
// 行末のセミコロンを省略
function do_something1() {
console.log("Do something!")
return 0
}
// インデント幅がスペース4 つ
// 関数名がキャメルケース
// 関数宣言の波括弧の前で改行
function doSomething2()
{
console.log("Do something!!");
return 0;
}
しかし,
- 注5)
- Pythonのように,
インデント幅などが意味を持つ言語の場合は動作が変わる場合があります。
スタイルの違いがバグを生む
コーディングスタイルの違いがバグの原因になることもあります。もとのコードがリスト2のようなとき,failed
が真であればdo_
が実行されます。そこで仕様の追加があって,do_
のあとにfinalize()
も実行することになったとしましょう。しかしリスト3のようにまったく同じ形で修正を施すと,finalize()
が実行されるというバグが埋め込まれてしまいます。これはJavaScriptやC言語などでたまに見かけるバグです。
リスト2 処理を追加する前のコード
// if 文に波括弧を付ける
if (failed) { ┓
do_fallback(); ┣(a)
} ┛
別のファイルでは……
// if 文に波括弧を付けない
if (failed) ┓
do_fallback(); ┛(b)
リスト3 処理を追加したあとのコード
// if 文に波括弧を付ける
if (failed) { ┓
do_fallback(); ┣(a)
finalize(); ┛
}
別のファイルでは……
// if 文に波括弧を付けないと
// if 文の対象が直後の文のみになってしまう
if (failed) ┓
do_fallback(); ┣(b)
finalize(); ┛
プロジェクト全体で
しかしコーディングスタイルが統一されていないと,
つまり,