第３章　上司が問題

同じことを書くな

ほとんど同じことの繰り返しになっている部分が多々見受けられます。きっと、エディタでコピーして、ちょこちょこっと直して作ったのでしょう。本人はきっと早くできて、満足でもしているのでしょうね。フローチャートがそうなんだから、プログラムにそういうのがあるのは当然なのでしょう。

でも、これは諸悪の根源みたいなものです。同じようなことを繰り返して書くのなら、何らかの工夫をすると、一度書けば済むように共通化できるはずです。

さらに悪いことは、同様の部分をコピーで作ったプログラムは、保守性が著しく低下してしまうことです。コピーして、４個所がほとんど同様で、その中を変更する必要が起きた場合には、４ヶ所に対して同様の変更しなければいけません。１個所でも忘れてはいけません。でも、人間は忘れっぽいもので、忘れて、バグに悩むものです。だからこそ、似たような部分は１つにまとめてしまうべきなのです。

人間は失敗する（バグる）ものです。だから、できるだけ失敗の可能性が減るようなプログラミングを心がけましょう。

■同じ構造体■

struct RECA と struct RECB の内容は全く同じです。こういう場合は、少なくとも

    struct REC {
        char     FLG[1];
        char     FNAME[15];
        char     TIME[5];
    } reca[1000], recb[1000];

とすべきです。元の書き方では、配列reca, recb はそれぞれ別の名前の構造体になっていて、別の型になってしまいます。このプログラムでは直接これが影響していませんが、多くの場合問題になるはずです。それに、このように書いた方が楽でしょう。楽をするとバグは減るものです。

配列のサイズはマクロ定義したいものです。できれば、この構造体を、typedefで新しい型として宣言し、

    typedef struct {
        char     checked;
        char     name[15];
        char     time[5];
    } file_spec;
    file_spec    rec_from[FILE_MAX_COUNT];
    file_spec    rec_to[FILE_MAX_COUNT];

のように書いたらいかがでしょうか。配列名も意味を表すものに変更しました。