Pocket

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

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

以下の例は、javascriptです。

1行に1関数

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

デバッグしにくい例

func_b内にステップインしたいとします。1回目の「ステップイン」でfunc_aにステップインします。func_a内から「ステップオーバー」でこの行に戻ります。2回目の「ステップイン」でfunc_bにステップインします。

デバッグしやすい例

func_bの行で止まり「ステップイン」すると、func_b内にステップインします。

if文の条件と本体は別の行にする

if文の条件部分と本体を1行にすると、ifの本体を通ったのかわかりにくくなります。

デバッグしにくい例

ステップ実行すると、if文の条件のtrue/falseに関係なく、次の行に進みます。条件が成立したのか、しなかったのか、func_aを呼んだのか、呼ばなかったのか、がわかりづらいです。

デバッグしやすい例

ステップ実行すると、if文がtrueなら、func_a()の行で止まります。

if文の条件を関数化する

if文の条件式が複雑だと、式内のどの条件がtrue/falseなのかわかりにくくなります。

デバッグしにくい例

このif文が予想外の結果だとします

デバッグしやすい例

関数の引数で、別の関数を呼ばな

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

デバッグしにくい例

func_bの戻り値を確認するには、func_aにステップインする必要があります。
また「1行に関数を2つ以上書くと、2つめ以降の関数にステップインしにくい」と同じように、func_bにステップインするまでの操作が多くなります。

デバッグしやすい

func_a(b);の行で止まると、変数のbの値が表示されます。

return式で関数を呼ぶない

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

デバッグしにくい例

func_aの戻り値を確認できません。

デバッグしやすい例

return result;で止まると、変数resultの値が表示されます。

1式1関数

1行1関数のバリエーションです。右辺の式内で2つ以上の関数を呼ぶと、戻り値を確認しにくいです。

デバッグしにくい例

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

デバッグしやすい例

2行目まで進めば、変数aの値が表示されます。3行目まで進めば、変数bの値も表示されます。

最近のAPIの名前は長いので、1行で複数のAPIを呼ぶと、1行が長くなってしまいます。長い1行にしても、折り返したしても、読むとき追いかけにくいです。1つづつAPIの戻り値を変数に代入すると、読みやすくなります

関数の戻り値は変数に代入する

1行1関数、1式1関数の究極バリエーションです。

デバッグしにくい例

こんな簡単な式でも、これ以降の処理で想定外な動きがあると、次のようにyの値を表示して確認することになります。

yの値を表示してみたけど、予想した値ではない場合、さらにfunc_a()の値を表示して確認することになります。

console.logを削除したものが、次の「デバッグしやすい例」です。

デバッグしやすい例

あやしい動きのとき、各行の直後にconsole.logを書くことで、変数の値を表示できます。デバッガでステップ実行したときも値を確認しやすいです