実用を考えると、文字列リテラルとの比較は文字列リテラルが先のほうが見やすい

java

もう落ち着いた話題だけど、SwingWorkerのサンプル書いて思い出した。
文字列リテラルの比較の話だけど、"リテラル".equals(s)よりもs.equals("リテラル")のほうが見やすいとか意味を反映しているとかあった。
けど、実際にJavaで文字列リテラルの比較などという無粋なことをする場合は、select〜case的な使い方をすることがほとんどであるような気がする。


PropertyChangeListenerであれば

if("progress".equals(evt.getName(){
  ・・・プログレスバーの処理
} else if("width".equals(evt.getName()){
  ・・・幅がかわったときの処理
} else if("height".equals(evt.getName()){
  ・・・高さがかわったときの処理
}

のような。
HTTPだと

if("GET".equals(method)){
  ・・・
} else if("POST".equlas(method)){
  ・・・
}

とか。
で、最初のifの位置がずれて気持ち悪いので、わざとダミーのifを入れたりする。

if(false){
} else if("GET".equals(method)){
  ・・・
} else if("POST".equlas(method)){
  ・・・
}

ちなみに、このifはコンパイラによって消し去られるはずなので、処理効率は気にしないでいいと思う。


そうすると、リテラルとの比較は、リテラルが先に来たほうが見やすい。まあ、結局同じ位置にリテラルが来るのだから、好みだろうけど。
意味としても、methodと"GET"の比較、methodと"POST"の比較、という気持ちではなくて、"GET"の場合、"POST"の場合、という気持ちで書いているのだから、methodとかequalsとか、ごちゃごちゃしたものは後ろにまわしてしまいたい。equalsIgonoreCaseを使うほうが多かったりするしね。
で、このとき、methodがnullでもそれなりに動いて問題の発現が遅れて困るとかいう意見は、「ん〜なんのこと？」という感じになる。まあそういう可能性がある場合もあるのだろうけど、少なくともぼくの書いてるコードの場合は、nullならほっとけばいいことがほとんどなので、関係ないことが多い。それより、nullとかどうかじゃなく、該当がない場合はすべからくエラーという処理のほうが多い。


"リテラル".equals(s)は嫌がらせとしか思えないという意見もあったけど、実のところそれは、文字列の比較を行っていること自体が嫌がらせだったりするんじゃないだろうか？と思ったりもする。
まあ、こういう書き方がいいとか悪いとかで意見が割れるときは、だいたいどっちも正しいのだから、どういう使い方を前提にしてるか明確にすると議論しやすいね。