if / elseまたはブール式によるブール代入のどちらがより保守性が高いですか?


11

どちらがより保守性が高いと考えられますか?

if (a == b) c = true; else c = false;

または

 c = (a == b);

Code Completeで調べてみましたが、答えが見つかりません。

最初のほうが読みやすいと思います(文字通り大声で読むことができます)。2番目の方法は確かに理にかなっており、コードを削減しますが、C#開発者にとってそれが保守可能であるかどうかはわかりません(たとえば、このイディオムはPythonでもっと見られると思います)。


3
2つは同等ではありません。else c = false最初にを必要とするか||=、2番目に割り当てを行います。

17
最初のフォームを2回編集しなければならなかったという事実があなたの質問に答えると思います!
ジェームズ

7
@Jamesに同意します。2番目の形式は、冗長ではありませんが、理解するのは非常に簡単であり、その意味についてあいまいさはありません。実行されるトリックやショートカットはありません。概念が単純であるため、短いだけです。最初のバグをバグでコーディングし、それを修正するためにそれを編集しなければならず、それでも完全でない(中括弧の一貫性のない使用)という事実は、あなたが思っているほど簡単ではないという証拠です。
エリックキング

5
うわー、C#開発者は本当に最初のフォームを受け入れられると考えていますか?これは...彼らに対する私の信頼を深刻に低下させます。私の経験では、最初の形式の使用は、ブール式の完全な誤解を強く示唆しています。
アンドレスF。

2
面白くするために、別のオプションをc = a==b ? true : false;
次に示し

回答:


14

2番目のオプションの方が優れています。

コードの意図を曖昧にして保守性を損なう巧妙なプログラミングショートカットに注意する明確な理由があります。ですから、私はあなたに質問をしたことを責めません。

しかし、私はc = (a == b);巧妙なトリックの例とは考えていません。それは単純な概念の単純な表現です。できるだけ簡単です。

最初の例の適切な「保守可能な」フォーマット(不足しているブレースと1行のコンストラクトはなく、賢いショートカットと思います)は、次のコードを生成します。

if (a == b)
{
    c = true; 
}
else 
{
    c = false;
}

私の経験では、このような冗長でエラーを起こしやすい方法で単純なブールロジックを記述することは、「簡単な」コードの兆候です。このコードベースでより複雑なロジックがどのように処理されているのか不思議に思うでしょう。


15

まず、2つのフォームが同等ではないことを理解してください。

if (a == b) c = true;

cがにa等しい場合はtrueに設定されb、等しくない場合、その値は既にあるもののままになります。

c = (a == b);

cがにa等しい場合はtrueに設定されb、等しくない場合はfalseに設定されます。

最初のフォームのスタイルで、2番目のフォームに相当するものが必要な場合は、次のように記述する必要があります。

if (a == b) {
  c = true;
} else c = false;

これで、2つのうちどちらが読みやすく、保守しやすく、何かが変更された場合にバグが発生する可能性が低くなります。2番目のフォームに固執します。


まったく正しい-私は質問を更新しました。
ブレットウォーカー

過度に長く複雑な2番目の形式を検討します。その効果が必要な場合は、ブール割り当てを使用します。
モニカの復活-M.シュレーダー

11

最初のフォームの方が読みやすいことに同意しません-1行に2つのステートメントがあるのは確かに慣用的なC#ではifなく、ブレースを使用せずにステートメントを作成することはお勧めできません。

第二に、2番目のフォームの保守性が低いことがわかりません。保守するものがありません。それは関係の簡単な声明だab、それはもはや単純に表現することができませんでした。

2番目の形式を好むもう1つの理由cは、単一のステートメントで宣言して割り当てることができるということです。

bool c = (a == b);

変数を変更すると、簡単にエラーが発生する可能性があるため、回避します。ifステートメントを使用するには、変数を条件の前に宣言してから変更する必要があります。


私は擬似コードとして1行に2つの文を読んで
ジミー・ホッファ

1
Another reason to prefer the second form is that you can declare c and assign it in a single statement」の+1
アンドレスF.

0

「より保守しやすい」ことは非常に主観的です。

私は通常、コード削減よりも読みやすさと意図を好みます。縮小フォームを使用して、8文字の入力文字を保存すると思います。

言語を取り巻く言語と文化を取り入れることは、私の意見では「読みやすさ」の特徴です。

結果として得られるバイトコードを最適化するためにコードを削減するためにパフォーマンスが原因となる場合がありますが、プロファイリング後に慎重に行う必要があります。


主観的:当たり前。コード削減:(過剰にされていない場合でも)明瞭さを改善し、意図をよりよく伝えることができます。パフォーマンス:まったく関係ありません(最適化が重要な場合もありますが、カーネルやドライバーを作成している場合でも、ほとんど問題にならないため、これは最適化に該当するものではありません)。

4
最初のフォームには、修正が必要なバグが少なくとも1つありましたが、その冗長性は隠されていました。2番目の形式はシンプルで要領がよく、バグはありませんでした。ケースを休ませます。いずれにせよ、主な目的はより少ない文字を入力することではありませんでした!そして、この質問はパフォーマンスに関するものではなく、この場合は無関係です。
アンドレスF.

@delnanまさに私のポイント、Duh。誰かのコード削減は、他の誰かの明快さです。私は主な関心事として最適化を引用しませんでした...私はそれを例として使用しました。巧妙なトリックを追加したり、標準から外れたりする理由は、あなた/文化/企業が読みやすいと考えるものとバランスを取る必要があります。
ジョニー

1
クリーンなブール式を書くことは賢いトリックではありません!
アンドレスF.

あなたが実際に質問の精神に取り組み、基礎となる概念を支持するために使用される異常な類推ではない場合、私はあなたのコメントにより多くの価値を置くと思います。
ジョニー

0

二番目。これは、その、あまりの繰り返し(DRY)を持ち、何が起こっているかを理解することが容易であるcかどうかの値に保持しているaことがb同じです。

私見、さらに良いでしょう

c = a == b

私が書くように

  • 1 + 2 + 3 の代わりに ((1 + 2) + 3)
  • 5 + 3 * 7 の代わりに (5 + (3 * 7))

明らかに、些細な不必要なコードは美徳ではありません。散らかっています。


-4

投票者、私の修正された答えの何が悪いのか詳しく説明してください。

はい、c = (a == b);読みにくい場合があります(さらに悪いことに、StyleCopは不必要な括弧について文句を言います)が、私はまだのシンプルさが好きですa == b。したがって、ここで私はときの両方を使用することが好きなものであるab同じです。

private static bool NoPeriod
{
    get
    {
        return this.MyWaveLength == this.HerWaveLength;
    }
}

そして、あなたは次のことができますthis.c = this.NoPeriod

this.c = this.MyWavelength == this.HerWaveLength;

1
意味ですか、return this.MyWaveLength = this.HerWaveLength;それともreturn this.MyWaveLength == this.HerWaveLength;代わりに?
ジェシーC.スライサー

5
何!?c = (a == b);エラーが発生しやすいわけではありません。元の質問の最初の形式は、エラーが発生しやすいことです。OP自体が、バグを修正するために質問を編集しなければならないことによって示されています。
アンドレスF。

あなたの提案した解決策にはバグがあると思います= vs. ==
Ondra

@OndraMorský、ありがとう...コンパイラは私のためにこれを見つけたでしょう。
仕事

6
StyleCopには慣れていませんが、不必要な括弧が悪いことを示している場合は、無効にする必要があります。コンパイラーにとって不要な括弧は必要ありませんが、人間の目には非常にいいものです。c = a == bと書いた場合; コンパイラーはそれをうまく理解できますが、人間にとっては難しいです。
マイケルショー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.