4

私は他の誰かのコードに取り組んでおり、次のようなものを見ています:

if ((somevariable) >  decimal.Parse("24,999.99")) ...

return int.Parse("0");

代わりにこれを行う論理的な理由を考えることはできません

if ((somevariable) > 24999.99) ...

また

return 0;

私は何が欠けていますか?

4

4 に答える 4

8

元のコードと提案された変更の間には意味上の違いがありますが、あなたは懐疑的です。

文字列からの変換は単純にばかげています、ごめんなさい。これを行う必要はありません。違いは、元のコードは文字列を。として解析しますdecimalが、変更では。を使用することdoubleです。したがって、次のようになります。

if (somevariable > 24999.99m) ...
于 2012-04-04T22:12:24.280 に答える
7

一つには、24999.99はdouble値ではなく値であるため、decimalを使用することをお勧めします24999.99m。しかし、そうでなければ、文字通りを使用する方がはるかに良い考えです。(変数の周りの括弧も気にしません。)

小数点記号がない、または千単位の区切り文字がない一部のカルチャで実行された場合でも、解析を実行するコードは失敗することに注意してください。これを使う理由は思いつかない.,

于 2012-04-04T22:13:07.400 に答える
1

あなたは何も見逃していません。そのコードは偽物です。質問で説明した方法でリファクタリングします。

それが価値があるものについては、ではなく、decimal.Parse("24,999.99")を返します。したがって、最初の抜粋は実際には24999.99mdecimal24999.99double

if (somevariable > 24999.99m)

もちろん、これは、比較の右側のオペランドが実際にはである必要があることを前提としていdecimalます。このコードの性質を考えると、私はすべての正しさを疑うでしょう。

于 2012-04-04T22:12:54.480 に答える
-1

解析内の文字列は、変数としてではなく、文字列リテラルとして実際に入力されましたか?

もしそうなら、これは恐ろしいコーディングだと思います。彼らがこれをホットスポット関数に入れなかったことを願っています。その場合、それは貧弱なコーダーの兆候です。それらのいくつかが存在すると聞きました。

彼らは、数字を読みやすくするコンマを見るという利点を望んでいたかもしれません。(つまり、eeek!残りのコードについてはおそらく警告されます...)

于 2012-04-04T22:17:10.147 に答える