デバッガでトレースしやすい書き方

IDEのデバッガには、1行づつの「ステップ」、関数の中へ入る「ステップイン」、関数から戻る「ステップオーバー」、ローカル変数やメンバー変数の値を表示する機能があります。式の一部分を指定して評価する機能もありますが、その操作をする必要があります。

「ステップイン」することなく、「ステップ」だけでどこを通っているかを確認できたり、関数の戻り値を確認できると、デバッグしやすいです。

以下の例は、架空の言語です。

1行に関数を2つ以上書くと、2つめ以降の関数にステップインしにくい

デバッグしにくい例
func_b内にステップインするためには、1回目の「ステップイン」でfunc_aにステップインします。「ステップオーバー」でこの行に戻ります。2回目の「ステップイン」でfunc_bにステップインします。

func_a(); func_b();

デバッグしやすい例
func_bの行で止まり「ステップイン」すると、func_b内にステップインします。

func_a();
func_b();

if文の条件部分と本体を1行にすると、ifの本体を通ったのかわからない

デバッグしにくい例
ステップ実行すると、if文のtrue/falseに関係なく、次の行に進みます。funcを呼んだかどうかがわかりづらいです。

if (1 < a) { func(); }

デバッグしやすい例
ステップ実行すると、if文がtrueなら、func()の行で止まります。

if (1 < a) {
    func(x);
}

if文の条件式が複雑だと、デバッグしにくい

デバッグしにくい例

if (x <= func_a() && y <= func_b()) {
}

デバッグしやすい例

function is_xxxx(x, y) {
    a = func_a();
    b = func_b();
    f1 = x <= a;
    f2 = y <= b;
    f = f1 && f2;
    return f;
}

if (is_xxxx(x, y)) {
}

関数Aの引数で関数Bを呼ぶと、関数Bの戻り値を確認しにくい

デバッグしにくい例
func_bの戻り値を確認するには、func_aにステップインする必要があります。
また「1行に関数を2つ以上書くと、2つめ以降の関数にステップインしにくい」と同じ問題があります。

func_a(func_b());

デバッグしやすい例
func_a(b);の行で止まると、変数のbの値が表示されます。

b = func_b();
func_a(b);

return式で関数Aを呼ぶと、関数Aの戻り値を確認しにくい

デバッグしにくい例
funcの戻り値を確認できません。

return func();

デバッグしやすい例
return result;で止まると、変数resultの値が表示されます。

result = func();
return result;

右辺の式内で関数を呼ぶと、戻り値を確認しにくい

デバッグしにくい例
func_aやfunc_bにステップインしないと、戻り値を確認できません。

x = func_a() + func_b();

デバッグしやすい例
x = a + b;の行で止まると、変数aや変数bの値が表示されます。

a = func_a();
b = func_b();
x = a + b;

判断と処理を分けて読みやすくする

判断と処理を分けると、読みやすく、テストしやすく、デバッグしやすくなります。

例は javascriptで書いています。

1.初期バージョン

最初に書くバージョンはだいたいこんな感じです。
「もろもろの処理」は、複数行だったり、if文やfor文を含むことがあります。

function func2 (a, b) {
    if (a > 10) {
        if (a > 20) {
            if (a > 30){
                もろもろの処理_1
            } else {
                もろもろの処理_2
            }
        } else {
            もろもろの処理_3
        }
    } else {
        もろもろの処理_4
    }
}

2.もろもろの処理をそれぞれ別メソッドにします。

function func2 (a, b) {
    if (a > 10) {
        if (a > 20) {
            if (a > 30){
                func2_1();
            } else {
                func2_2();
            }
        } else {
            func2_3();
        }
    } else {
        func2_4();
    }
}

function func2_1() {
    もろもろの処理_1
}

function func2_2() {
    もろもろの処理_2
}

function func2_3() {
    もろもろの処理_3
}

function func2_4() {
    もろもろの処理_4
}

3.「判断」と「処理」を別メソッドにします。

function func2 (a, b) {
    var num = case_number(a, b);
    process(num);
}

function case_number(a, b) {
    var num = 0;
    if (a > 10) {
        if (a > 20) {
            if (a > 30){
                num = 1;
            } else {
                num = 2;
            }
        } else {
            num = 3;
        }
    } else {
        num = 4;
    }
    return num;
}

function process(num) {
    switch (num) {
        case 1:
            func2_1();
            break;
        case 2:
            func2_2();
            break;
        case 3:
            func2_3();
            break;
        case 4:
        default:
            func2_4();
            break;
    }
}

4.判断内のif文のネストをelse〜ifで小さくします。

function case_number(a, b) {
    var num = 0;

    if (a <= 10) {
        num = 4;
    } else if (a <= 20) {
        num = 3;
    } else if (a <= 30) {
        num = 2;
    } else {
        num = 1;
    }

    return num;
}

5.デシジョンテーブル風のコメントをつけておきます。

/*
| # | a     | action  |
| - | ----- | ------- |
| 4 | <= 10 | func2_1 |
| 3 | <= 20 | func2_2 |
| 2 | <= 30 | func2_3 |
| 1 | > 30  | func2_4 |
*/
function func2 (a, b) {
   ...
}

6. if文の条件式が長いときは、それぞれ別メソッドにします。

function case_number(a, b) {
    var num = 0;

    if (is_later_equal(a, 10)) {
        num = 4;
    } else if (is_later_equal(a, 20)) {
        num = 3;
    } else if (is_later_equal(a, 30)) {
        num = 2;
    } else {
        num = 1;
    }

    return num;
}

function is_later_equal(a, x) {
    var f = (a <= x);
    return f;
}

最後に、func2メソッドの処理をとりだして、別クラスにします。

三項演算子はデバッグしにくい

三項演算子はデバッグしにくいので、デバッグしやすさという観点では使わないほうがいいと思います。

三項演算子の例

x = (a < b) ? a : b;

if文の例

if (a < b) {
    x = a;
} else {
    x = b;
}

理由1:
デバッガでステップ実行したとき、if文のほうが処理の流れを追いやすいから。

三項演算子の文をデバッガでステップ実行すると、単に次の行に移動します。行を追っているだけでは、aとbのどちらを採用したのかがわかりません。a, b, xの値を読んだり、式を評価する必要があります。

if文をステップ実行すると、if の次に、x = a; または x = b; の行に移動します。どの選択肢に移動したのか、ひと目でわかります。

理由2:
選択肢が3つ以上になったとき、if文で書き直すから。

今は選択肢が2つですが、近い将来3つに増えるかもしれません。三項演算子で書いてあれば、if〜else if文で書き直すでしょう。それなら、今、if文で書いたほうがいいと思います。

理由3:
三項演算子を入れ子にした難解なコードを見たことがあるから。

見た瞬間、ここ触りたくねーと思いました。

この記事を書いた後、自分のソースを検索したら、予想より多く見つかりました。まあそんなもんですね。

この記事のタグは「コーディングスタイル」より「デバッガブル」だなと思い、「デバッガブル」で検索したら、いい記事が見つかりました。
デバッグしやすい、解析しやすいコードを書こう