2011年11月11日金曜日

nullと比較するif文かくときに、一歩レベルあげる書き方

多くの言語で

if($hoge == null)

といった書き方をしますが、少しの工夫で後の多大な
バグ取りの時間を防げるかもしれません。

その「少しの工夫」の書き方とは下記のとおりです。

if(null == $hoge)

逆にしただけです。なぜこの書き方が良いのか説明します。


まず前提として多くの言語では
$hoge=1;
という代入が成功した場合、"true"を返す仕様になっています
※1 ためしてみたところ、PHPの$hoge=null;でもtrueがかえります。
※2 javaは代入された値そのものがかえるようです。

つまりif($hoge = null) という文が文法エラーとならず成り立ってしまいます。
たった一個=を忘れただけで全く意図しない動きになり、かつあとから修正するときも
非常に気づきにくいバグです。

ですが

if(null == $hoge)

と書くことによってたとえば

if(null = $hoge)

と書いてしまっても、nullに代入ができるわけではないので
コンパイルエラーや実行時エラーになります。よって早い段階でミスに気づけます。


この書き方の大きなメリットは上記の単純ミスに気づくというだけではなく、
いかにしてバグの起こりにくいソースを書くかという意識づけができることです。
PGやSEの大切な仕事として「いかにしてヒューマンエラーを防ぐか」がありますが
こういった些細な書き方一つがその意識向上のきっかけになつていただければ幸いです。

2011年11月4日金曜日

Javaの数値チェックでNumberFormatExceptionを使ってはいけない理由

この前、Javaの半角数値チェックでぐぐっていたらわりと下記みたいな
ソースコードを見つけました

private static boolean isNumeric(String hoge) {
 try {
  Integer.parseInt(hoge);
  return true;
 } catch(NumberFormatException e) {
   return false;
 }
}

これは動きとしては正しい結果をだしますが
好ましくありません。
下記のような書き方のほうが好ましいです


private static boolean isNumeric(String hoge){
 char c = null;
 for (int i = 0 ; i < hoge.length(); i++){
  c = hoge.charAt(i);
  if (c < '0' || c > '9'){
    return false;
  }
 }
 return true;
}


理由1
Javaはガベージコレクションのおかげでスマートなメモリ管理を
可能ですが、例外もあります。それは名の通り"例外"の時です。

Exceptionがthrowされると一時的でもヒープを大幅に使うので
やはりexceptionはなるべく避けるように使うべきです。

これが何十万件のデータを処理するバッチならば当然避けるべきです

理由2
上記とかぶりますがExceptionはその名の通り、「例外」ですので
プログラマの想定しなかったケースのみ発生するようなあり方が
好ましいためです。チェックのために使うというのはプログラム設計
としてよろしくないためです(※理由2は個人的見解です)



余談
たとえばほとんど数値以外の文字が入ってくること無いが
想定される場合はNumberFormatExceptionを使うケースでもよいかもしれません

ただその場合NumberFormatExceptionをthrowする、あるいはラッピングされた
なんからのExceptionをthrowするという設計のほうが正しい気もしますが