日々常々

ふつうのプログラマがあたりまえにしたいこと。

キョウミタコード

List list = hoge();
if (list.size() >= 1) {
    for (Object o : list) {
        // hoge
    }
}

ぱっと見て isEmpty 使えよと思ったけど、そもそも if 要らない…。

Annotation annotation = clz.getAnnotation(HogeAnnotation.class);
if (annotation != null) {
    // annotation を使わない処理
} else {
    annotation = clz.getAnnotation(FugaAnnotation.class);
    if (annotation != null) {
        // やっぱり annotation を使わない処理
    } else {
        annotation = clz.getAnnotation(PiyoAnnotation.class);
        if (annotation != null) {
            // もちろん annotation を使わない処理
        } else {
            // 段々畑が続く
        }
    }
}

せめて isAnnotationPresent 使ってくだしあ。


こういうのが平然とプロのコーディングとして行われているわけですが、なぜそんなことになるかというと設計書の通りに書くことが何よりも重要だからです。例えば前者の例では「1件以上取得できた場合云々」とか書いてます。そのまま書くと上記の通りのコードが出来上がるわけです。こんなことだからプログラミングは単純作業なんて言われてしまう。
設計書の通り書くことの何が良いかというと、設計書の通り書いてれば何かあったときに設計者の責任になることです。また外因では、コードレビューが「設計書にある行がプログラムのどの行に対応しているかを確認する作業」になってたり、「テスト項目を設計書の一行一行に対して作られている」などが挙げられます。
設計がインタフェースに対して行われているならばそのアプローチもありかもしれません。しかしながら、冗長とも言える前述のような定型的な記述は、プログラミング言語だと自然言語よりも簡潔かつ誤り無く表現出来ます。がんばって詳細な処理を自然言語で書くのが詳細設計ならば、そんなもん要らない。


問題なく動くから良いって意見もあるかもしれません。読まなくて良いならそれでも良いでしょう。それなら目の触れないようにしておくべきです。私の目に触れてるので、だめ。


バグってたわけですが

冗談抜きに、こーゆーのを書かずに済むなら、書き間違えなんてのも起こらないのです。見る方も「間違ってんじゃないか?」とか思う必要もありません。身をもってこーゆーのを書くことのあれさをですね。ええ。ちくしょう。