<< Prev Page Next Page >>

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


安全なコード

きしださんの記事を読んで、うん、Javaだとそういう苦労、あるよね。と、うなづいてた。

「こちらのほうが美しい」という理由よりも、「こちらのほうが安全」という理由で書き方を選んだほうがいい。こういった細かい選択がプログラムの信頼性をあげていく。
なんも考えずに"リテラル".equals(s)と書け - きしだのはてな
そしたら、意外と"リテラル".equals(s)っていう書き方が不人気っぽいので援護だよ。

その書き方に「うわ、気持ち悪い」と思う気持ちはよく知ってる。

つまり、まあ例えば、与えられたStringが"get"だったらこうして、"put"だったらああする、みたいな事を書くときに
「文字列sが"get"に等しい」という式はオブジェクト指向で考えれば主語がsなのだから、「s.equals("get")」と書くべきだ
と思う気持ち。僕も最初の頃はそんな風に考えてた。

で、こうなるのかな。
if (s.equals("get")) {
こうする
} else if (s.equals("put")) {
ああする
}
で、これだとsにもしかしてnullが来たらエラーになっちゃうじゃんって言われて、nullチェックはそもそもメソッドの先頭なりでやるべきで、とかそんな話にこんがらかっていく。

でも、何度も何度もいろんな絶望を味わっていくと、
if ("get".equals(s)) {
こうする
} else if ("put".equals(s)) {
ああする
}
としか書きたくなくなる(nullのこととか考えるの面倒臭い)。あるいは、
switch($s) {
case "get":
こうする
break;
case "put":
ああする
break;
}
とか
case s
when "get"
こうする
when "put"
ああする
end
とか書ける言語に行ってしまってそんな悩みを忘れてしまう(←僕いまここ)…いや、それはともかく。

で、僕に限らずみんな味わう絶望ってどんなのかというと、ほんと色々で、
似たような処理30カ所実装してたら1カ所だけnullチェックしてなかった…
とか、
ライブラリのAPIリファレンスに、その返値はStringで、存在しない場合は空文字列が返るって書いてあるのに!
とか、
oracleでは空文字が返るけどmysqlではnullが返るとかそんなんアリかー
とか、
僕が書いたメソッドではちゃんとメソッド先頭でnullチェックしてるのに、新人君がその部分だけコピペしてnullチェック書いてなかったんだよ!
とか
メソッド先頭でせっかくnullチェックしてんのにその後でnullを代入するコード書いたヤツが悪いんだよ!
とか。で、
直すっていってももう次の仕事に取りかかってて時間取れないよう、また時間外勤務かよう
みたいな。

え、他人の作った不具合まで面倒見るなんておかしい?そりゃー、幸せな職場なのか、まだ自分の地位が低いのか。「誰のせいでも知らんからとにかく直せすぐ直せ今直せ。」っていわれるイヤ~な世界に足をつっ込まないよう引き続き気をつけてください。

あと、くっそーって思ってCVSのヒストリ見たらその悪い奴って新人君じゃなくて自分だったりとかな。死ねよ自分、って絶望する瞬間。

きしださんが言う「安全」っていうのは、そのコードをどんな風に酷く扱っても、説明書にダメって書いてあることやっても壊れない子ども向けオモチャみたいな頑丈さのことだと思う。

もちろん、どんなコードでもそこまで頑丈に作れるはずなんてないけど、Stringをリテラルと比較する程度の単純なロジックは、少ない行数で頑丈に作れるならそっちを選択したほうがいい。それが読みにくいっていうなら、それがすんなり読めるように自分を慣れさせたほうがいい。


この記事に対するコメント

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

【2008/12/15 11:51】 | #[ 編集]

この記事に対するコメントの投稿



管理者にだけ表示を許可する

この記事に対するトラックバック

トラックバックURL
http://tockri.blog78.fc2.com/tb.php/171-4c817bee
この記事にトラックバックする(FC2ブログユーザー)

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。