どのような重複検出しきい値を使用しますか?[閉まっている]

Question

重複は悪であり、避けるべきであるということには誰もが同意します (「重複しない原則」)。それを確実にするには、静的解析コードを次のように使用する必要があります。 シミアン (多言語) または クローン探偵 (Visual Studio アドイン)

読んだばかりです アイエンデさんの神戸に関する投稿 ここで彼はこう言っています：

神戸の8.5%はコピペコードです。そして、それは感受性です しきい値を設定した場合、高くダイヤルされました から 3 までは、私がよくやっていることですが、 12.5%まで上がります。

3という敷居は非常に低いと思います。私の会社では、高品質のコード分析をサービスとして提供していますが、重複のデフォルトのしきい値は 20 に設定されており、重複が多数あります。3にするとお客様は修正のことすら考えられなくなると思います。

コービーについてのアイエンデの意見は理解できます。これは公式のサンプルであり、「Web 2.0 アプリケーションおよびサービスの計画、設計、および実装をガイドすることを目的としている」と販売されているため、品質への期待は高いです。

しかし、あなたのプロジェクトでは、重複に対してどのような最小しきい値を使用しますか?

関連する質問: コードの重複をどれほど熱心に排除していますか?

Answer 1

経験則としては 3 つですが、状況によって異なります。重複を排除するためのリファクタリングでは、多くの場合、コードベースと API の概念的な単純さを犠牲にして、一度理解すれば保守しやすい小さなコードベースを得る必要があります。私は通常、この観点から物事を評価します。

極端な例として、重複を修正することでコードが読みやすくなり、コードの概念的な複雑さがほとんどまたはまったく増加しない場合、いかなる重複も受け入れられません。この例としては、複製されたコードが、説明と名前が付けやすい何かを実行する単純な参照透過関数にきちんと分解される場合が挙げられます。

メタプログラミング、OO デザイン パターンなど、より複雑で重量のあるソリューションの場合。が必要な場合は、特に複製されたスニペットが小さい場合は、4 つまたは 5 つのインスタンスを許可することがあります。このようなケースでは、解決策の概念的な複雑さが、実際に多くの事例が発生するまでは、治療法を病気よりも悪くしていると私は感じます。

最も極端なケースとしては、私が取り組んでいるコードベースが非常に急速に進化するプロトタイプであり、合理的にシンプルで合理的に将来性のある抽象化ラインを描くためにプロジェクトがどのような方向に進化するのかについて十分な知識がない場合です。ただ諦めます。このようなコードベースでは、たとえ同じコードが 20 回複製されたとしても、優れた設計よりも便宜性と物事の完了に重点を置いたほうが良いと思います。多くの場合、重複を作成しているプロトタイプの部分は、いずれにしても比較的すぐに破棄されるものです。プロトタイプのどの部分が保持されるかがわかれば、いつでもこれらをリファクタリングできます。破棄される部分によって追加の制約が作成されない場合、多くの場合、この段階ではリファクタリングが簡単になります。

Answer 2

何が適切な「指標」なのかはわかりませんが、私が通常努力していることは次のとおりです。

• 同じコードが 2 か所にある場合、
• コードは意図的に同じです (単に偶然同じではなく)

次に、リファクタリングして重複を削除します。すべての重複は悪です。コードを 2 か所に置くことはめったになく、3 か所では必ずコードを移動する必要があります。

Answer 3

私は個人的にそれについてかなり熱狂的です。私はコードの重複を避けるようにプロジェクトを設計するようにしています。しきい値を一桁の下位にするという目標はありますが、そこに到達できない場合は、設計が十分ではないことを意味し、振り出しに戻るかリファクタリングする必要があります。

Answer 4

プログラミング言語によって異なります。(「クローン探偵」の人はこれを認識しているようです:「プログラミング言語の制約」は彼の最初のプレゼンテーションのボックスの 1 つです。)

Lispプログラムでは、 どれでも 重複した式は簡単にリファクタリングの対象になります。これをしきい値 2 と呼ぶのでしょう。すべては式で構成されており、式を翻訳するマクロがあるため、一度でも何かを複製する言い訳はほとんどありません。(抽出が難しいものとして私が思いつく唯一のものは、LOOP 句のようなものです。実際、多くの人がまさにその理由で LOOP を避けることを主張しています。)

他の多くの言語では、プログラムはステートメントを持つメソッドを持つクラスで構成されているため、式を取り出して 2 つの異なるファイルで使用することは困難です。多くの場合、それは抽出するときにその構造を変更することを意味します。多くの場合、タイプ セーフの要件もありますが、これは制限となる可能性があります ( 沢山 それを回避するために常にリフレクション コードを使用しますが、そうする場合は静的言語を使用すべきではありません)。現在の静的型付けプログラムを完全に DRY にした場合、プログラムは短くもならず、保守も容易ではありません。

結局のところ、私たちが本当に求めているのは「メンテナンスの容易さ」ということだと思います。言語によっては、「コピーした内容とその理由を示すコメントをここに入力するだけ」を意味する場合もあります。DRY は、コードが保守可能かどうかを示す優れた指標です。何度も繰り返す場合、それは良い兆候ではありません。しかし、単一の統計を追うことも悪い傾向にあります。そうでなければ、単にその統計を最適化するだけですべての問題を解決することになります。

Answer 5

組み合わせる必要があると思います

• 重複する行数
• 重複がコピーされた回数
• 重複が互いにどの程度「近い」か
  たとえば、異なる製品がたまたま同じソース コード管理システム内にある場合、それらが同じメソッド内にある場合とは大きく異なります。
• 重複したコードを含むメソッドが変更されてからの時間。

重複を削除するコストと利益の間で適切なトレードオフを得るために。

Answer 6

私たちの クローンDR 言語構文でパラメータ化された大規模なソース システム全体で、正確なコピーとニアミスの両方の重複コードを検索します。Java、C#、COBOL、C++、PHP、その他多くの言語をサポートしています。

「クローンとは何ですか?」を定義するために、次のような多数のパラメーターを受け入れます。a) 類似性の閾値、2つのコードブロックの類似性を制御する 宣言されたクローン(通常は95%が良好) b) 最小クローン・サイズ(3行が適している傾向がある) c)パラメータの数(テキストへの明確な変更。5が良い選択になる傾向があります) これらの設定では、仮想的に10〜15%の冗長なコードを見つける傾向があります 処理するすべてのもの。