痛いソース・オブ・ザ・イヤー

中規模システムの保守を行っている同僚Mが頭を抱えていたのを見かけた。
面倒なので無視しようと思ったが、かわいそうなので話を聞いてあげた。

彼曰く、
あるenumに定義を追加したところ、全体的に動作がおかしくなった。
そのenumは、Webサイトのページの識別子で50個ほど定義がある。
仕方ないのでそれを使用している他のソースを調べてみたところ、
enumをわざわざ配列化し、それのインデックスを用いて値を指定していた。


以下のようなソースだ。

enum Itai {
    A,
    B,
    C,
};



if( ... ) {
  return Itai.values()[0];
} else if( ... ) {
  return Itai.values()[1];
} else {
  return Itai.values()[2];
}

※本物は、Itai.values()がメソッド化されていたり(それも痛い)複雑極まりない作りになっている

で、追加した定義はenumの途中だったので、インデックスがずれてしまい、バグってしまった。
これを直すには、ずれたインデックス指定をすべて+1しなくてはいけないが、
そもそも色々と納得できない!


間違いない。
今年見た中で最も痛いソースだ!
このソースを書いた人が誰かは知らないが、痛い・オブ・ザ・イヤーを進呈しよう
同僚Mよ、キミの憤りは正当だ。ご愁傷さま!(爆笑)

コメント

このブログの人気の投稿

nginxでlocalhostとしてアクセスをサーバーに転送する方法

Android・・・テキスト描画あれこれ, ascent(), descent()等

Android:stateに応じてTextの色を変更する・・・ColorStateList