プログラムには流れがある

プログラムを書くときには正常時処理とエラー（異常時）処理がありますね。エラー処理は例外的な処理ですから、ソースコード上では正常時処理が中心になるような書き方をすべきです。このことは、他人が見たときや後で自分が見るときに理解しやすいソースコードにするために重要です。

次の悪い例を見て下さい。

bool BadOne()
{
    FILE *fp = fopen( "output", "w" );
    if ( fp == 0 ) {
        return false;
    }

    if ( fputs( "abc", fp ) != EOF ) {
        fclose( fp );
        return true;
    }

    fclose( fp );
    return false;
}

ファイルに文字列を出力し、上手くいったら true を返すという関数です。書き方にポリシーがないため、正常時の通り道がどこだか見つけにくくなってしまっています。fopen のあとでは失敗したかどうかを判定しているのに対して、fputs のあとでは成功したかどうかを判定しています。しかも関数の最後まで辿り着くのは失敗時だというのも良くありません。

次は、より改善された例です。

bool BetterOne()
{
    bool bSuccess = false;

    FILE *fp = fopen( "output", "w" );
    if ( fp != 0 ) {

        if ( fputs( "abc", fp ) != EOF ) {
            bSuccess = true;
        }

        fclose( fp );
    }

    return bSuccess;
}

はじめの例に比べてだいぶスッキリした感じになっているでしょう。それに、この例では次のようなポリシーが貫かれているため、正常時の通り道が見つけやすくなっています。

• if 文では正常ルートへの判定を行う（正常時は if 節に進み、異常時は else 節に進む）
• 必ず関数の最後まで到達する（return 文が１ケ所にしかない）
• 同じ処理（ここでは fclose）を何度も書かない

正常時の通り道が見つけやすいと、関数がどのようなアルゴリズムで書かれているのかが明確になります。複雑さが軽減され、読みやすく、また改造しやすいソースコードになります。その方が良いに決まっています！

このような書き方をする場合に注意すべき点が１つあります。それは、ちょっと気を抜くといつのまにかネストが深くなって見づらくなってしまうことです。いまの例では正常終了までの間に if が２つしかないので良いですが、もっと多い場合もしばしばです。その場合は適当な深さのところでサブルーチン化して見やすさを保つように心掛けましょう。

もうひとつ、別のポリシーで書かれたコードを挙げておきます。

bool BetterAnother()
{
    FILE *fp = fopen( "output", "w" );
    if ( fp == 0 ) {
        return false;
    }

    if ( fputs( "abc", fp ) == EOF ) {
        fclose( fp );
        return false;
    }

    fclose( fp );
    return true;
}

この例では次のようなポリシーが貫かれています。

• if 文で異常を検出し、異常発生時には即座に return する
• 正常時のみ関数の最後まで到達する

正常時の通り道はかなり見つけやすいですが、以下のような弱点があります。

• return を複数ケ所で書くと構造化が破壊されるため PAD などで表現できない
• 同じ処理（ここでは fclose）を何度も書かなければならないので、改造のときにやや面倒

２つの異なるポリシーを挙げましたが、ほとんどの場合はこの２つの書き方で事足りてしまいます。通常は前者のポリシーで書き、後者はこちらを使った方が分かりやすくなりそうな場合に用いるようにすれば良いでしょう。