私は他の誰かのコードに取り組んでおり、次のようなものを見ています:
if ((somevariable) > decimal.Parse("24,999.99")) ...
と
return int.Parse("0");
代わりにこれを行う論理的な理由を考えることはできません
if ((somevariable) > 24999.99) ...
また
return 0;
私は何が欠けていますか?
私は他の誰かのコードに取り組んでおり、次のようなものを見ています:
if ((somevariable) > decimal.Parse("24,999.99")) ...
と
return int.Parse("0");
代わりにこれを行う論理的な理由を考えることはできません
if ((somevariable) > 24999.99) ...
また
return 0;
私は何が欠けていますか?
元のコードと提案された変更の間には意味上の違いがありますが、あなたは懐疑的です。
文字列からの変換は単純にばかげています、ごめんなさい。これを行う必要はありません。違いは、元のコードは文字列を。として解析しますdecimal
が、変更では。を使用することdouble
です。したがって、次のようになります。
if (somevariable > 24999.99m) ...
一つには、24999.99はdouble
値ではなく値であるため、decimal
を使用することをお勧めします24999.99m
。しかし、そうでなければ、文字通りを使用する方がはるかに良い考えです。(変数の周りの括弧も気にしません。)
小数点記号がない、または千単位の区切り文字がない一部のカルチャで実行された場合でも、解析を実行するコードは失敗することに注意してください。これを使う理由は思いつかない。.
,
あなたは何も見逃していません。そのコードは偽物です。質問で説明した方法でリファクタリングします。
それが価値があるものについては、ではなく、decimal.Parse("24,999.99")
を返します。したがって、最初の抜粋は実際には24999.99m
decimal
24999.99
double
if (somevariable > 24999.99m)
もちろん、これは、比較の右側のオペランドが実際にはである必要があることを前提としていdecimal
ます。このコードの性質を考えると、私はすべての正しさを疑うでしょう。
解析内の文字列は、変数としてではなく、文字列リテラルとして実際に入力されましたか?
もしそうなら、これは恐ろしいコーディングだと思います。彼らがこれをホットスポット関数に入れなかったことを願っています。その場合、それは貧弱なコーダーの兆候です。それらのいくつかが存在すると聞きました。
彼らは、数字を読みやすくするコンマを見るという利点を望んでいたかもしれません。(つまり、eeek!残りのコードについてはおそらく警告されます...)