最初は「良いコード」を書くための知識や心構えから話そうか

「良いコード⁠」⁠！ いろいろ想像しちゃいます。芸術的なコード，1バイトの無駄もないコード……

いや，チーム開発という前提のもとでは，必ずしもそういうものがいいとは限らないんだ。わかりやすい基準だと，私はたとえばこういうコードが一般的に「良いコード」だと思うよ

• プロジェクトに参加したばかりの人でも，無理なく理解できる
• 長期的にメンテナンスしやすい（変更を加えたり，バグを修正したりしやすい）

えっ，そんなことでいいんですか？

そんなこと，が大事なんだ。これができてないコードばっかりじゃあ，チームとして一緒に作業できないよ？ これができてようやく，スタートラインってところだね。じゃあさっそく，コードの見た目の問題から見ていこうか

コーディングスタイルとは

プログラムのアルゴリズムやロジックとは無関係に，書きかたが分かれる場面があります。たとえば，よく知られたところでは次のような項目があります。

• インデント（字下げ）の幅
  • 半角スペース2文字分でインデントする
  • 半角スペース4文字分でインデントする
  • 半角スペース8文字分でインデントする
• インデントのしかた
  • タブ文字でインデントする（ハードタブ）
  • インデントの幅に相当する数の半角スペースで行う（ソフトタブ）
• スペースの空けかた
  • function ( arg1, arg2 )のようにスペースを空ける
  • function(arg1,arg2)のようにスペースを詰める
• 複数単語が連なる識別子（注1）の書きかた
  • 小文字の単語とアンダースコアでvariable_nameのように書く（注2）
  • 先頭の単語はすべて小文字，2つ目以降の単語は先頭文字を大文字にしてvariableNameのように書く（注3）
  • 単語の先頭文字を大文字にしてVariableNameのように書く（注4）
• 改行の位置
  • 関数の宣言では型名のあとで改行するのか，しないのか
  • 関数の宣言やif文では波括弧の前で改行するのか，しないのか

このような違いはコーディングスタイルと言われます。コーディングスタイルはコーディング規約の一部としてプロジェクトごとに定められている場合があり，プログラミング言語やOSS（Open Source Software）のプロジェクトによってどのようなコーディング規約が定められているかをまとめたWikipediaの記事もあります。

注1）

変数名，関数名，クラス名，モジュール名などのことです。

注2）

蛇の体がうねる様子になぞらえて「スネークケース」と呼ばれます。

注3）

ラクダの背中のこぶになぞらえて「キャメルケース」と呼ばれます。

注4）

キャメルケースの変形として「アッパー（大文字の）キャメルケース」と呼ばれます。あるいは，Pascal という言語で初めて採用された書きかたであることから「パスカルケース」とも呼ばれます。

スタイルがバラバラのコードは読みづらい

次のような理由から，1つのプログラムの中でも場所によってコーディングスタイルがそろっていないことがあります。

• 複数人で開発する際に，コーディング規約が決まっていなかった
• 別のプロジェクトからコードを引用した
• その場しのぎで適当に直したものがそのまま残った
• 前任者からの引き継ぎが不十分だった

文法エラーになるような致命的な間違いと異なり，コーディングスタイルの違いは見た目の差だけでプログラムの動作に影響がない場合が多い（注5）ため，あまり注意が払われないこともあります。そのため，コーディングスタイルがファイルごとに異なっていたり，それどころかリスト1のように同じファイルの中で異なっている場合すらあったりします。

// インデント幅がスペース2 つ
// 関数名がスネークケース
// 行末のセミコロンを省略
function do_something1() {
  console.log("Do something!")
  return 0
}

// インデント幅がスペース4 つ
// 関数名がキャメルケース
// 関数宣言の波括弧の前で改行
function doSomething2()
{
    console.log("Do something!!");
    return 0;
}

しかし，このようにコーディングスタイルが統一されていないコードは，読みづらく，コードを理解するのに時間がかかります。また，精神的に疲れるために，間違ったり間違いを見落としたりしやすく，コードを誤読したりバグを埋め込んでしまったりしてしまう可能性が高まります。

注5）

Pythonのように，インデント幅などが意味を持つ言語の場合は動作が変わる場合があります。

スタイルの違いがバグを生む

コーディングスタイルの違いがバグの原因になることもあります。もとのコードがリスト2のようなとき，（a）でも（b）でもfailedが真であればdo_fallback()が実行されます。そこで仕様の追加があって，do_fallback()のあとにfinalize()も実行することになったとしましょう。しかしリスト3のようにまったく同じ形で修正を施すと，（b）では常にfinalize()が実行されるというバグが埋め込まれてしまいます。これはJavaScriptやC言語などでたまに見かけるバグです。

// if 文に波括弧を付ける
if (failed) {     ┓
  do_fallback();  ┣（a）
}                 ┛

別のファイルでは……
// if 文に波括弧を付けない
if (failed)         ┓
  do_fallback();    ┛（b）

// if 文に波括弧を付ける
if (failed) {     ┓
  do_fallback();  ┣（a）
  finalize();     ┛
}

別のファイルでは……
// if 文に波括弧を付けないと
// if 文の対象が直後の文のみになってしまう
if (failed)       ┓
  do_fallback();  ┣（b）
  finalize();     ┛

プロジェクト全体で「if文では必ず波括弧を付ける」というスタイルが徹底されていればこのバグは発生しませんし，「⁠if文で実行する処理が1つだけのときだけは波括弧を付けない」スタイルが徹底されている場合も，このような変更には注意が向けられるためバグの発生を防ぎやすいでしょう。

しかしコーディングスタイルが統一されていないと，たまたま波括弧が付いていた個所だけを見て前者のスタイルと早合点してしまい，波括弧の追加が必要な個所を見落としてしまいかねません。

つまり，コーディングスタイルを統一していないとバグ発生のリスクが高まるということが言えます。括弧の付けかた一つでバグを埋め込む可能性が減るのであれば，コーディングスタイルを統一することには大きな意義があります。