- PR -

文字列をequalsで判定する時

«前のページへ 11|12|13|14|15|16|17|18|19|20|21 次のページへ»
投稿者投稿内容
あぶぽん
大ベテラン
会議室デビュー日: 2005/10/20
投稿数: 205
投稿日時: 2008-02-14 13:42
引用:

無害化とは空文字列の代入を意味しています。


そっちの意味でしたか。

引用:

例えばWEBシステムを作っていたとします。


それはよくやります。
たしかに、それも僕の『事前に行なうこと』の項目に入りますね。

この場合、メソッドの冒頭に…などではなく、
初期化時にすべて空文字に初期化するという仕様であり、対策ですね。
（これは仕様で統一されていないと不味い。コーディング規約レベルではないですね）

ジョーク無害化の正しい使い方というか。。。（笑）

# 僕が以前に見たというのは、正しくない使い方のほうです。
# さすがに同じ関数内ではやってませんが、呼び出し側で、
# 呼んでみたら例外が発生したので代入したみたいな程度のものでした。。。
rain
ぬし
会議室デビュー日: 2006/10/19
投稿数: 549
投稿日時: 2008-02-14 13:42
コード:
if (str == null) {
  str = "";
}

if (str.equals("")) {
  // ...
}


このコードだと、str が nullのときはコメント部分を通るわけですが、
私は "".equals(str) との比較というのが頭にあったので、
これだと等価にならないんじゃないのかな、と思っていました。

無害化がかつのりさんの仰るような意味だったということは、
むしろ意図通りだったということですね。無粋なつっこみすみませんでした。

そういえば、.NET 2.0 で初めて String.IsNullOrEmpty(string s)
というメソッドがあることを知ったときは、
「わざわざこんなん作らなくても」と思ったものですが、あると便利なのは確かですね。
カーニー
ぬし
会議室デビュー日: 2003/09/04
投稿数: 358
お住まい・勤務地: 東京
投稿日時: 2008-02-14 14:03
引用:

rainさんの書き込み (2008-02-14 13:42) より:
コード:
if (str == null) {
  str = "";
}

if (str.equals("")) {
  // ...
}


このコードだと、str が nullのときはコメント部分を通るわけですが、
私は "".equals(str) との比較というのが頭にあったので、
これだと等価にならないんじゃないのかな、と思っていました。


ごめんなさい、それは僕のミスです。
皆さんには概ね意図を汲んでいただけていたようで安心していますが、文脈的には否定の!を入れるべきでした。
あぶぽん
大ベテラン
会議室デビュー日: 2005/10/20
投稿数: 205
投稿日時: 2008-02-14 15:00
引用:

rainさんの書き込み (2008-02-14 13:42) より:
そういえば、.NET 2.0 で初めて String.IsNullOrEmpty(string s)


僕はC#プログラマでもありますが使いませんね。

それがインスタンス・メソッドなら良かったのに。。。と、
思いましたが、そうなると、言語仕様的に無理ですから。。。（笑）

　if (middleName.IsNullOrEmpty()) {

クラス・メソッドなら左右逆になるので、
左辺・右辺とか数学的にこだわる訳ではなく、

「設計書（もしくはテストケース）」と順番が逆だから！

#「ヌルか空文字なのがミドルネームなら…」と書いてあれば、
# 使うかもです ＜ String.IsNullOrEmpty(string s)
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2008-02-14 16:09
引用:

それがインスタンス・メソッドなら良かったのに。。。と、
思いましたが、そうなると、言語仕様的に無理ですから。。。（笑）

拡張メソッドなら、恐らく期待通りになるかと思います。
rain
ぬし
会議室デビュー日: 2006/10/19
投稿数: 549
投稿日時: 2008-02-14 16:26
脱線部分ばかり反応してすみません。

引用:

かつのりさんの書き込み (2008-02-14 16:09) より:
引用:

それがインスタンス・メソッドなら良かったのに。。。と、
思いましたが、そうなると、言語仕様的に無理ですから。。。（笑）

拡張メソッドなら、恐らく期待通りになるかと思います。



拡張メソッドを使って、
コード:
if (middleName.IsNullOrEmpty()) { 
    ...
}

と書けたとしても、middleNameがnullだとやっぱり例外になったりしませんか？
無理というのはそういう意味だと思いました。

# 猛烈にVisualStudio2008を触りたくなってきた
あぶぽん
大ベテラン
会議室デビュー日: 2005/10/20
投稿数: 205
投稿日時: 2008-02-14 16:47
引用:

rainさんの書き込み (2008-02-14 16:26) より:
と書けたとしても、middleNameがnullだとやっぱり例外になったりしませんか？
無理というのはそういう意味だと思いました。


その辺の話、Insider.NETのほうでしません？

自分でスレ立てればいいのですが、.NETは入門者なので。。。
KOX
大ベテラン
会議室デビュー日: 2004/08/23
投稿数: 142
投稿日時: 2008-02-14 18:00
なんか、すごいことになってますね。

なんて書いてよいか、分からなかったので
今まで書き込んでいませんでした。
以前に、自分のブログの中でこの件に関して話題にしたことがありました。
http://blogs.wankuma.com/kox/archive/2007/07/12/84863.aspx

僕の中では、str.equals("hoge");を基本的に使うという結論に至りました。
可読性を意識してのことではありません。
可読性に関しては、僕はどちらでもあまり変わらないと思っていますので。

保守といった観点での場合の話を少し書こうと思います。
nullを考慮し忘れた場合のバグが多いのはnagiseさんと同意見です。
僕が遭遇してきた障害のほとんど場合は
"hoge".equals(str)
で解決できるのも同意見です。

それでも、あえてstr.equals("hoge")を基本的に使うことにしました。
#もちろんケースバイケースで"hoge".equals(str)を使用することもあります。

・理由１
if("hoge".equals(str)){
}else{
//何かしらの処理
str.equals("foo");//Exception発生
}
この場合、str.equals("foo")でExceptionが発生するから問題なしと思われるかもしれません。
ですが僕はExceptionになるなら「何かしらの処理」が行われる前に分かりたい。
どの段階でstrがnullになっていたのかをstrの内容を遡って解析するのは大変です。

・理由２
"hoge".equals(str)が正常に動作してうまくいっていたが、
意図した結果になっていなかった場合。
正常に動作している（Exceptionが発生しない）ため、どこで不具合が発生しているのかわからない。
つまりどこでnullの考慮もれが発生しているのかの原因の特定が困難になってしまう。
どの段階でstrがnullになっていたのか、というよりもnullが原因で意図した結果にならなかったのかさえ
判断しづらくなります。
また、意図していない結果に気づかずそのまま運用しつづけて不具合が発生した場合、
データのリカバリー＆洗替えを行う必要が出てしまうくらいなら、
Exceptionで落ちてから修正したほうが影響が小さいと思われるからです。

運用時に発生する不具合で、
str.equals("hoge")を使用して発生したバグと
"hoge".equals(str)を使用して発生したバグを天秤にかけたとき
str.equals("hoge")を使用して発生したバグのほうが
影響が小さいであろうというのが僕が経験してきた保守の中での結論です。
«前のページへ 11|12|13|14|15|16|17|18|19|20|21 次のページへ»

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