36

すべてを緑色にしようとしているときに、Resharper から次の提案を受けました。

元のコード:

    static public string ToNonNullString(this XmlAttribute attr)
    {
        if (attr != null)
            return attr.Value;
        else
            return string.Empty;
    }

提案: 冗長な「else」を削除すると、次のようになります:

    static public string ToNonNullString(this XmlAttribute attr)
    {
        if (attr != null)
            return attr.Value;
        return string.Empty;
    }

私には、提案されたバージョンはオリジナルよりも読みにくいようです。Resharper の提案は、優れた保守可能なコードの定義を反映していますか?

4

14 に答える 14

49

技術的には、「else」が不要であるという点で Resharper は正しいですが、意図がより明白であるため、以前のバージョンを好みます。

そうは言っても、私はむしろ一緒に行きたい：

return attr != null ? attr.Value : string.Empty;
于 2009-01-21T23:00:00.567 に答える
31

ああ、コードの美学。聖戦の時。(アヒル)

?: 式のいずれかを使用します。

return attr != null ? attr.Value : String.Empty

または if を反転し、改行を削除してガード句を生成します。

if (attr == null) return String.Empty;

return attr.Value;
于 2009-01-21T23:08:30.983 に答える
22

if を逆にすると、新しいバージョンの方がはるかに優れていると思います

static public string ToNonNullString(this XmlAttribute attr)
{
    if (attr == null)
        return string.Empty;

    return attr.Value;
}

null-case は特殊なケースですが、元のバージョンは対称的すぎるためです。

新しいバージョンは、「ほとんどの場合何を返すか」という点でより読みやすくなっています。

于 2009-01-22T07:31:07.443 に答える
10

コードの最初のバージョンの方が読みやすいことに同意します。

これらのケースでは、Resharper の提案が必ずしも役立つとは限りませんが、問題を解決できる場合もあります。そのため、変更を「提案」ではなく「ヒント」として表示するように Resharper を構成しました。これにより、緑色の下線が見えにくくなり、右側のサイドバーで強調表示されなくなります。

于 2009-01-21T22:58:17.403 に答える
8

ReSharper が何かを提案する方法が気に入らない場合は、特定の提案を無効にしてください(スラッシュ警告スラッシュヒント)。同じことがコーディング スタイルにも当てはまり、非常に高度な設定が可能だと思います。ReSharper が使用不能であると主張する (「生き残れなかったと言ってうれしいです。ここでは誰ももう使用していません」と引用します) 構成方法を理解するのに 5 分もかからないという理由だけで、ただのばかげた行為です。

もちろん、コーディング スタイルの一部をツールに指示させるべきではありません。そうしないように指示した場合、ReSharper はそれを行いません。それはとても簡単です。

于 2009-02-25T15:38:41.553 に答える
4

元のコードははるかに読みやすく、理解しやすくなっています。ひと目で、string.Empty返される原因となる条件を正確に確認できます。がない場合は、その前にブロックにelseリターンがあることを確認する必要があります。if

覚えておいてください、あなたは人間であり、機械よりも本質的に賢いのです。何かがより良いと言っていて、同意しない場合は、耳を傾けないでください。

于 2009-01-21T23:12:42.117 に答える
3

私のコーディング標準は常に角かっこを使用することです（ifコマンドの後に命令が1つしかない場合でも）
これには少し手間がかかります（より多くの入力が必要です）が、非常に価値があると確信することがよくあります。

最も一般的なバグの1つ（そして逆説的に見つけるのが難しい）は、ifステートメントの後に追加の命令を追加し、角かっこを追加するのを忘れることです...

だから私はResharperが提案したものが好きです。特にネストされたifステートメントがある場合：

このコードがあると仮定します。

   if (condition1)  {
      instruction1;
   }
   else {
       if (condition2) {
           instruction2;
       }
   }

次のように変更できます。

   if (condition1)  {
      instruction1;
   }       
   else if (condition2) {
      instruction2;
   }

そして、これは以前よりもはるかに読みやすくなっています。
（2レベル以上のネストされたステートメントがある場合にも、より見やすくなります）

于 2010-08-25T07:10:16.793 に答える
1

ベストプラクティスとコーディング標準に関しては、常に議論の余地があります。この理由の1つは、VisualStudioのようなIDEを使用して簡単に適用できないことです。標準のコードを分析するために使用できるFxCopやStyleCopなどの利用可能なツールがあります。FxCopはコンパイルされたコード分析に使用され、StyleCopはソースコード分析に使用されます。

コードに適用するフォーマットに関して、StyleCopを分レベルに構成できます。VisualStudio内に提案を提供するResharper用のStyleCopと呼ばれるアドインがあります。同じことについての詳細なブログ投稿が http://nileshgule.blogspot.com/2010/10/refactoring-clean-code-using-resharper.htmlにありました。

于 2010-10-06T11:39:22.477 に答える
1

小さなサンプルサイズを使用すると、すべてに忍び寄る例外の典型的な例。巨大な if-elseif-else ブロックをガード句のレイアウトにリファクタリングすると、コードがはるかに読みやすくなりますが、あなたが言うように、同じルールを単一の if-else に適用すると、それほど役に立ちません。このような非常に小さなブロックをスキップしないようにすることは、リシャープの開発者による (わずかな) 先見の明の欠如であるとまで言えますが、それは十分に無害です。

于 2009-01-21T23:23:09.520 に答える
1

「attr != null」条件は初期の救済 (またはユースケースの例外パス) と見なすことができ、関数がその主なタスクを続行できるため、リシャーパー バージョンの方が優れています。（私からハイタッチを勝ち取ることもありません。私は複数のリターンが嫌いです）。

この場合、MrWiggles シングルライナーが最良の選択肢だと思います。

于 2012-02-22T15:10:30.533 に答える
1

私が追加する唯一のことは、関係する式の長さに関係します。個人的には三項式のコンパクトさが好きなのですが、

if (testDateTime > BaseDateTime)
    return item.TransactionDate <= testDateTime && item.TransactionDate >= BaseDateTime;

return item.TransactionDate >= testDateTime && item.TransactionDate <= BaseDateTime;

のようなものに

return testDateTime > BaseDateTime ? item.TransactionDate <= testDateTime && item.TransactionDate >= BaseDateTime : item.TransactionDate >= testDateTime && item.TransactionDate <= BaseDateTime;

私にはあまり役に立たないようです。

于 2010-08-23T15:23:42.703 に答える
1

ReSharper についても同じことに気づいたので、一部のアイテムをオフにしたり、警告レベルを下げたりできる機能に感謝しています。私もこの提案に当惑しています：

SomeClass varName = new SomeClass();

に提案された変更があります:

var varName = new SomeClass();

はい、最初の宣言型が必要ないことはわかっていますが、var 形式が他の形式よりも優れていると示唆するのは奇妙に感じます。提案の背後にある理論的根拠に精通している人はいますか、それともこれも奇妙であることに同意しますか?

于 2009-01-21T23:18:27.673 に答える
1

C# の初心者であり、C と Java に慣れている私は、C# .NET と VS での山かっこの配置にまだ慣れることができません。それはさておき、「if」を反転するとさらに読みやすくなるという点で、アンドレイに同意します。一方、「else」を省略すると、可読性が（わずかに）低下することが個人的にわかります。私はこれで個人的に行きます：

static public string ToNonNullString(this XmlAttribute attr)
{    
    if (attr == null)
        return string.Empty;
    else
        return attr.Value;
}
于 2009-02-25T15:31:29.900 に答える
0

私の同僚の何人かは、編集したページでその瞬間から Resharper を使い始め、レイアウトと読みやすさがひどいものでした。生き残っていないことを嬉しく思います。ここではもう誰も使用していません。

手元のステートメントについては、Jeffrey Hantin に同意します。インライン if は、このようなタイプのステートメントには非常に優れており、Whatsit のソリューションは非常に受け入れられます。いくつかの例外を除いて、私は（個人的に）メソッド/関数にはreturnステートメントが1つだけあるべきだと言います。

また、（ほとんど）常にifでelseを実装している場合（elseステートメントで何もしないことを示すコメント行に他ならない場合でも）、その状況について考える必要があります。ミスを防ぎます。

この種の問題のほとんどと同じように、常に頭脳を使ってください :) ほとんどのエラーは、そうしないときに発生します。

結論として、Resharper にはノーと言いましょう。(はい、Resharper は本当に嫌いです。申し訳ありません。)

于 2009-01-22T07:52:41.253 に答える