第10章の内容について、議論の対象となった部分を引用する。

10.3 変数の初期化のガイドライン

変数は最初に使用する場所の近くで初期化する

リスト10-2: 悪い初期化（Visual Basic）

' すべての変数を宣言する
Dim accountIndex As Integer
Dim total As Double
Dim done As Boolean

' すべての変数を初期化する
acountIndex = 0;
total = 0.0
done = False
...

' accountIndexを使用するコード
...

' totalを使用するコード
...

' doneを使用するコード
While Not done
...

…中略

リスト10-2の例では、done変数を宣言した後、done変数を使用するコードが実行されるまでに、done変数が変更される可能性がある。

…中略

もう1つの問題は、すべての初期化を1か所にまとめると、done変数は最後の方でしか使用されないにもかかわらず、すべての変数がルーチン全体で使用されるという印象を与えることだ。

…中略

これは、「関連する作業を1つにまとめる」という近接の法則の一例である。

なるほどなるほど。しかし僕は普段の業務でプログラミング言語らしきものはJavaScriptしか使わないので、JavaScriptに置き換えて考えよう。

var accountIndex = 0,
    total = 0,
    done = false;
// accountIndexを使用するコード
...

// totalを使用するコード
...

// doneを使用するコード
while(!done) {
    
}
...

これが本書で「悪い例」とされているコードをJavaScriptに置き換えたコードだ。しかし関数の先頭で var hoge = 0, fuga = false; のようにして変数をまとめて宣言（＆初期化）するのはJavaScriptではよく見られるコードだ。あのjQueryですらそのような記法を多用している。
JavaScript: The Good Partsによると

ほとんどの言語では、変数は一般的に最初に利用される場所で定義するのが最も良い方法だ。しかしこれは、ブロックスコープを持たないJavaScriptでは好ましくない。すべての変数は、それぞれの関数の先頭で定義したほうが良い。

とある。そう、JavaScriptはブロックスコープを持たない（{}でくくられた部分限定の変数スコープ）といういわゆる変態言語であり、変数のスコープを生成するのは関数ブロックのみだ。それが理由で、変数はまとめて関数の先頭で宣言するという記法がベストプラクティスとされている。

さてしかし、Code Complete第2版による「変数は最初に使用する場所の近くで初期化する」ほうがよいという理屈の続きはこうだ。

10.4.1 変数の参照はまとめて

変数を参照してから次に参照するまでのコードは、「脆弱性の窓」（無防備な時間帯）である。その窓では、新しいコードが追加されたり、何気なく変数が変更されたり、変数に含まれていなければならない値が忘れられてしまったりする。変数の参照は、常に近いところにまとめて局所化するのが望ましい。

…中略

これを測定する方法は、変数の「持続間隔」を計算することである。

…中略

リスト10-6: 1と0の持続間隔（Java）

a = 0;
b = 0;
c = 0;
b = a + 1;
b = b / c;

この場合、bの1つ目の参照と2つ目の参照の間にコードが1行あるので、その持続間隔は1である。bの2つ目の参照と3つ目の参照の間にはコードがないので、その持続間隔は1である。bの2つ目の参照と3つ目の参照の間にはコードがないので、その持続間隔は0である。

…中略

リスト10-6では、bの平均持続間隔は (1 + 0) / 2 = 0.5 である。変数の参照を近くにまとめると、コードの読み手がコードをセクションごとに読んでいけるようになる。

…中略

10.4.2 変数の「寿命」はできるだけ短く

変数の持続間隔に関連して、変数の「寿命」という概念がある。変数の寿命とは、変数が存続する期間内に存在するステートメントの合計である。

…中略

変数の持続間隔とは異なり、変数の寿命は、最初に参照されてから最後に参照されるまでの変数の使用回数を計算に入れない。変数が最初に1行目で参照され、最後に25行目で参照された場合、変数の寿命は25（ステートメント）である。

…中略

変数の持続間隔と同様に、変数の寿命もできるだけ短くする、つまりステートメントの数を少なくすることが目標となる。持続間隔と同様に、ステートメントの数を少なくすると、脆弱性の窓が小さくなるという利点がある。

…中略

寿命を短くするもう1つの利点は、コードを正確に把握できることである。変数に10行目で値を代入し、45行目まで使用しない場合、2つの参照の間に空いている空間は、変数がその間に使用されていることを暗示する。

…中略

変数の寿命が短いと、コードが読みやすくなる。読み手が一度に頭に入れなければならないコードの行数が少なければ少ないほど、コードは理解しやすい。

変数には「平均持続間隔」と「寿命」という概念があるという。そしてそれらが短くなった方がコードの読み手にとって読みやすいコードになるという。

去年、僕がとある案件で数千行に及ぶJavaScriptを書いた際、最も頭を悩ませたのはコードを頭に入れることだった。機能を追加・修正するために一度に頭に入れなければならないコードが多すぎたため、開発が進めば進む程、コードの修正は困難を極めた。

プログラミング初心者が誰しも一度はぶつかる壁なのかもしれない。コードの分割をはじめとする、コードの設計の重要性を肌で感じた瞬間だった。
だからこそ、上記の「読み手が一度に頭に入れなければならないコードの行数が少なければ…」というくだりに深く納得したのだった。

さて、ではJavaScriptにおいて「変数の寿命を短くする」ことと「関数の先頭ですべての変数を宣言する」ことは両立するのだろうか？これについて隣席の@keiskeyの意見はこうだった。

関数1つの長さ自体を短くしてしまうのがいいのでは。Google Closure Libraryのコードを見ていると、中身が2行しかないメソッドに長々とした名前が付いていたりする。そんな長い名前を付けるんだったら直接コードを書いてしまえばいいやん、と思うけど、「変数の寿命」のポリシーをもって書かれていると考えると合点がいく。

なるほど…と再び納得するとともに、「この話、共有してよかった」と思った。

例えば上述（リスト10-2）のコードを一つの関数だと考えるとこうなる。

function Account() {
    var accountIndex = 0,
        total = 0,
        done = false;
    // accountIndexを使用するコード
    ...

    // totalを使用するコード
    ...

    // doneを使用するコード
    while(!done) {
        
    }
    ...
}

この関数をクラス風に書き直し、機能分割するとこういう感じになる。

function Account() {
    // コンストラクタ
    ...
}
Account.prototype = {
    getAccountIndex: function() {
        var accountIndex = 0;
        // accountIndexを使用するコード
        ...
        return accountIndex;
    },
    getTotal: function() {
        var total = 0;
        // totalを使用するコード
        ...
        return total;
    },
    checkStatus: function() {
        var done = false;
        // doneを使用するコード
        while(!done) {
            ...
        }
    }
}

prototypeにぶら下げたメソッド1つ1つを短くまとめて上手に機能分割することが、限りなく正解に近いのではないかと思った次第。

僕はプログラマと呼ばれる職種ではないのだけれど、プログラミングに関わる人間として、こういった考察はとてもおもしろいと感じる。また何か同じような話があったら書いていきたい。