- PR -

文字列をequalsで判定する時

«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»
投稿者投稿内容
Edosson
ぬし
会議室デビュー日: 2004/04/30
投稿数: 675
投稿日時: 2008-02-08 15:11
引用:

unibonさんの書き込み (2008-02-08 14:51) より:

↑このコードをぱっと見ても、testStr に null がありうるのかどうかが分かりません。
入力時のタイプ数やソースコードのプリントアウトの字数は少なくなりますが、細かいロジックを見たいときには、逆に、思考の妨げになると思います。

nullかどうかなんてどうでもいい場合も多々ありますよ。
そういう場合は、nullかどうかなんて、最初から無視すればいい。

そもそも、nullかどうか意識しなくてもいいような
コーディングを心がける、という考え方もあるし。
コージ
常連さん
会議室デビュー日: 2005/07/29
投稿数: 39
投稿日時: 2008-02-08 15:27
unibonさん
Edossonさん

どうもありがとうございます。
お二人のおっしゃていることは十分理解できます。

①testStr != null && testStr.equals("test")
②"test".equals(testStr)

①、②どちらかがいいのではなく
状況に応じたコーディングが必要ですね。

そもそもNullPointerが起こりやすい作りはよくないですね。
さけれないところでもありますが。
だーて
常連さん
会議室デビュー日: 2007/12/18
投稿数: 20
お住まい・勤務地: ここはどーこ？私はだーて
投稿日時: 2008-02-08 22:01
こんばんは。

①の式が書かれていると、「なぜこういう処理にしたのか？」という疑問が沸きます。

なので、私が所属してる開発チームではコーディングルールを設けて、
②の式で統一されていますね。

こっちの処理では①、あっちの処理では②、とバラバラになっていては保守が大変だと思います。

状況に応じた、ではなく、全部統一させたほうがいいんじゃないかなと思いました。

_________________
普通？常識？何ですかそりは。
日本語は難しい・・・。
jama
常連さん
会議室デビュー日: 2006/09/12
投稿数: 45
投稿日時: 2008-02-08 23:12
私は①を使用します。
定数が左なのには抵抗があるから。
testStr != null && testStr.equals("test") を使用します。

①と②を書き間違えたのを修正。


[ メッセージ編集済み 編集者: jama 編集日時 2008-02-08 23:46 ]
OTAKE
会議室デビュー日: 2008/02/08
投稿数: 18
投稿日時: 2008-02-08 23:33
昔のCと同じような迷信が流行っているんですね。
Cだと、条件判断のときに定数を左に置くのが良いコードって信じていませんでした？
曰く、定数を左に置くと"=="と"="を打ち間違えたときに、エラーを見つけやすいからとか。
多分、javaで"hoge".equals(str)って書く人は、定数を左に置く人なんでしょうね。

比較対照が文字列定数と文字列変数かで、比較対照が右や左に変わるのって、コードが読みにくくなるのですが。
自分のコードを書くので精一杯なのは仕方ないかもしれませんが、読む人のことを考えてコードを書けるようになると、プログラマーとしてのスキルが上がりますよ。
さいくろう
大ベテラン
会議室デビュー日: 2005/11/19
投稿数: 170
お住まい・勤務地: 川崎市
投稿日時: 2008-02-09 00:40
妙なのが沸いてるな。
自分が受け付けないからって、それを一般化してどうするよ。

「定数」といってるが、特にここでStringを取り上げると、
Stringはいうまでもなく、単なるリテラルじゃない。
Objectを継承し、各種のメソッドを備えた、歴としたアプリケーションだ。
その「定数」がアプリケーションとして振る舞って、変数の判定を判定する、
と考えれば、なんの抵抗もない。
つか、nullかどうか、nullでないなら値に応じた処理を行う、という
メソッドを用意したっていいんだし。

Cのような手続き型言語では、ロジックと変数は、別物として扱うしかなかった。
人間がロジックを行使して、最初から最後まで、変数の面倒を見るしかなかった。
オブジェクト指向言語は違う。
変数（別に定数じゃなくていい）とロジックを一体化して、
ほかの変数の面倒を見ることを任せることができるのだ。

>定数を左に置く人なんでしょうね。

オブジェクトを、リテラルと変わらない扱い方しかできない、
メソッドをサブルーチンと同じものだと考えているようでは、
化石といわれても文句は言えないだろうよ。
未記入
大ベテラン
会議室デビュー日: 2008/02/07
投稿数: 115
投稿日時: 2008-02-09 11:37
引用:

A は testStr が null だった場合、NullPointerException になってくれるという"利点"があります。これは欠点ではなく"利点"だと私は考えます。

そうですね。testStr.equals("test") には、testStr != null というアサーションとしての効果もあるわけです。しかし、assert 構文に比べると、意図が伝わりにくく可読性が低いと思います。

引用:

if (testStr.equals("test")) であっても同様に null を期待していないことが分かります。

この書き方で testStr が null を期待していないと本当に分かりますか？ 他人の書いたコードであっても？ 自分が数ヵ月前に書いたコードであっても？

私は「このコードは null について考慮せずに書かれたものではないか」との心配をしてしまうこともあります。(特にうまく動作しないプログラムのデバッグをまかされたようなときは。)

null を期待していないのなら、それが分かるように書くべきでしょう。たしかに A の書き方にはアサーション効果がありますが、アサーションを期待して書かれたものかどうかを読み取ることはできません。このような明示されないアサーション効果は、細かいロジックを見たいときには、逆に、思考の妨げになると思います。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2008-02-09 12:29
> この書き方で testStr が null を期待していないと本当に分かりますか？

分かります。

> 他人の書いたコードであっても？

ちゃんとしたプログラマーが書いたコードなら分かります。

> 自分が数ヵ月前に書いたコードであっても？

分かります。

引用:

未記入さんの書き込み (2008-02-09 11:37) より:
私は「このコードは null について考慮せずに書かれたものではないか」との心配をしてしまうこともあります。(特にうまく動作しないプログラムのデバッグをまかされたようなときは。)

私は逆に "test".equals(testStr) というコードを見た場合「このコードは testStr が null のことを考慮して書かれているのだろうか？」と心配になります。たしかに equals メソッドは引数が null の場合と非 null の場合の両方を許しますが、両方のケースを網羅して動く条件判断をもくろんだコードなのかが、不安です。

引用:

未記入さんの書き込み (2008-02-09 11:37) より:
null を期待していないのなら、それが分かるように書くべきでしょう。たしかに A の書き方にはアサーション効果がありますが、アサーションを期待して書かれたものかどうかを読み取ることはできません。このような明示されないアサーション効果は、細かいロジックを見たいときには、逆に、思考の妨げになると思います。

これも、私は逆に null を(null も)期待しているのならば、それが分かるように書くべきだと思います。
また、コードが正しいという前提があれば、testStr.equals("test") を見れば、null を期待していないことは一目瞭然です。

もしもこれが分かりにくいというのならば、それは、コードが正しくないかもしれないという前提がある場合でしょう。しかし、そんな品質の低いコードまで考慮しないといけないのだとすれば、コードに書いてあることがなにもかも信用できなくなってしまいます。
ただし、これは "test".equals(testStr) であろうと testStr.equals("test") であろうと同じことです。
«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）