最終ライン効果の説明

マイクロクローンは、非常に小さなサイズの複製されたコードフラグメントであり、ほんの数命令または行です。 この記事では、「最後の行の効果」、つまり、マイクロクローンの最後の行または命令が以前の行または命令よりもエラーを含む可能性が高い現象を検討します。 この目的のために、219のオープンソースプロジェクトと、欠陥のあるマイクロクローンに関する263の警告を調査し、コードにこのようなエラーを起こした実際のアプリケーションの6人の著者にインタビューしました。 学際的な研究では、このタイプの比較的些細なエラーを引き起こす心理的メカニズムも研究されています。 調査とさらなる技術分析の結果に基づいて、いわゆる「シーケンスエラー」が最後の行効果の存在において重要な役割を果たしていると仮定します。 さらに、その起源を確立できたすべてのマイクロクローンは、異常に大きなコミットで発見されました。 この効果を知ることは、プログラマーにとって2つの有用な結果をもたらします。



1）ミクロクローンで間違いを犯す可能性が特に高い状況を認識しやすくなります。



2）自動マイクロクローン検出器/ PVS-Studioを使用できるため、このタイプのエラーの検出が簡単になります。

キーワード

マイクロクローン、コードクローン、コードクローン検出、最終ライン効果、心理学、学際的研究。

1はじめに

ソフトウェア開発者は、次のTrinityCoreプロジェクトの例のように、わずかな変更を加えて、1行のコードを数回連続して複製する必要があります。



例1



トリニティコア

他のオブジェクトの空間座標は、座標x、y、zに対応するフィールドに追加されますが、同じタイプの3行のこのフラグメントの最後の行にはエラーが含まれます。y座標がz座標に追加されます。 実際、最後の行は次のようになります。

次の例は、人気のあるChromium Webブラウザーから取得したもので、1行内の同じ種類の指示で問題の効果の発現を示しています。



例2



クロム

ホストの空行を二重チェックする代わりに、port_strの2番目のチェックを行う必要があります。

例1の1行目から3行目は、例2の行3のif演算子の条件と同様に、互いに類似しています。ほとんど同じ繰り返し行または命令で構成されるこのような非常に短いコードブロックは、マイクロクローンと呼ばれます。 ソフトウェア品質の問題の開発とアドバイスに関する私たち自身の経験から、マイクロクローンの最後の行または命令は以前の行または命令よりもエラーを含む可能性がはるかに高いことが直感的にわかりました。 この研究の目的は、私たちの感覚の真実を検証することであり、この研究の枠組みで提起された2つの質問を決定するのはこの目標です。

• RQ 1複数行のマイクロクローンの最後の行にエラーが含まれている可能性が高いというのは本当ですか？
• RQ 2 1行の長さのマイクロクローンの最後の命令にエラーが含まれている可能性が高いというのは本当ですか？

プログラムを書くときにコードのブロックをコピーすることはほとんどのプログラミング言語で使用されるため、ほとんどすべての開発者は最終行の影響を受ける可能性があります。 同じタイプのいくつかの連続した命令の最後がよりエラーが発生しやすいことを証明できれば、作成者とコードインスペクターはどのセクションに特別な注意を払うべきかを知ることができ、エラーの数を減らしてプログラムの品質を向上させるのに役立ちます。



コピーと貼り付けは、コードを作成する自然な方法の1つであり、例1および2に似ています。行ごとのコピーと貼り付けとコードセクションの「複製」。 これらのメソッドは、最も一般的なプログラミングのイディオムの1つであり（Kim et al。2004）、最小限の物理的および時間的コストで済むため、安価です。 さらに、そのようなコードが実行可能であることが知られています。 コードの小さなセクションをコピーすることはしばしば悪い習慣と見なされますが（Kapser and Godfrey 2008）、これが上記の例のように、プログラムの望ましい動作を実装する唯一の方法である場合があります。 マイクロクローンを検出し、可能であれば排除するために、いくつかのツールが開発されています（Bellon et al。2007; Roy et al。2009）。 これらのツールは方法のレベルまで印象的な結果を示しているにもかかわらず、誤検出が多すぎるため、実際のマイクロクローン認識にはあまり適していません。



人気の科学ブログで最後の行の効果に関する記事を公開した後、他のフォーラムで迅速かつ熱狂的に引用されました。 多くのプログラマーが私たちの観察に同意し、議論中の効果の背後に心理的な理由があることを示唆しました。 ここから、この研究の枠組みにおける3番目の最後の質問が来ます。

• RQ 3一般的に欠陥のあるマイクロクローンが存在する理由と、特に最後の行の影響は何ですか？

開発者の調査の結果、例の徹底的な技術分析、心理学者との協力に基づいて、心理的側面、もしそうであれば、どの側面が最終行の効果の発現に影響を与えるかを調べます。 認知心理学で長い間観察されてきた現象を研究してきたので、彼らの助けを借りてコードのマイクロクローンの最後の行の効果を説明することができるかどうかを見つけます。



最後の行の影響に関する以前の調査（Beller et al。2015）に基づいて、次の追加を行いました。

• 「マイクロクローン」という用語が導入され、定義されました。
• 従来の方法では検出できない欠陥のあるマイクロクローンを検出するために、自動静的分析ツール（Beller 2016）PVS-Studioで使用される診断を導入しました。
• 各エラーは、1,891個のアナライザー警告に基づいて、219の一般的なオープンソースプロジェクトから選択された263個すべてのマイクロクローンで個別に調査されました。
• 最後の行の効果の根底にある心理的メカニズムの予備分析を実施しました。
• マイクロクローンでミスを犯した実際のプロジェクトの6人の開発者にインタビューしました。
• エラーと異常に大きなコミットとの関係を示す調査に基づいて、4つの人気のあるオープンソースプロジェクトのリポジトリを調査しました。

観察結果から、例1および2で示したものと同様に、マイクロクローンの最後の行または命令は、以前の行または命令のいずれよりもエラーを含む可能性がはるかに高いことがわかります。 この現象の存在は、マイクロクローンの技術的な複雑さによるものではなく、心理的な理由によるものと思われます。これは、主にプログラマーの短期記憶を過負荷にすることに起因します。 5つのプロジェクトに基づく予備調査により、エラーのあるすべてのマイクロクローンは、標準外の勤務時間中に異常に大きなコミットで書き込まれたことが明らかになりました。 これらの機能を理解し、自動化されたPVS-Studio静的アナライザーを使用すると、それらを自動的に検出することにより、最後のライン効果に関連する些細なエラーの数を減らすことができます。

2研究計画

私たちの仕事は、C1とC2の実証研究の2つの部分で構成されています。 このセクションでは、研究を実施する手順とその目的について説明します。

2.1研究計画C1：ミクロクローンの最終列効果の有病率と有病率

5つの簡単に再現可能なステップで構成される研究C1では、マイクロクローンの最終列効果の有病率の統計分析を行いました。 さらに、マイクロクローンの作成プロセスに光を当てるために、コードの元のセクションとそのコピーを識別するための追加作業を行いました。

1. すべての診断を有効にしてPVS-Studioツールを使用して、研究オブジェクトの静的解析を実行します。 PVS-Studioはロシアの会社OOO Program Verification Systems LLCによって開発された商用の静的アナライザーであり、Cの特定のライブラリ関数を使用して、コードのクローンブロックの検出からプログラミングのアンチパターンまで、多数の診断ルールが含まれています。 PVS-Studioのオープンアクセス無料試用版。
   
   
   
   
2. PVS-Studioレポートを調べて、マイクロクローンに関連しないメッセージだけでなく、誤検知も削除します。
   
   
   
   
3. 欠陥のあるマイクロクローンごとに、コードの行の総数（RQ 1）または命令（RQ 2）をカウントし、エラーが表示される行または命令を示します。 可能であれば、元のコードセクションとそのコピーを決定します（たとえば、例6では、オリジナルは2行目で、コピーは3行目です）。
   
   
   
   
4. 研究を開始すると、デフォルトでは、長さn行の欠陥マイクロクローンでは、各行のエラー確率は、検討中のフラグメント内のその数に関係なく1 / nであるという仮定から進められます（仮説H0）。 たとえば、2行のブロックの1行目と2行目のエラー確率は同じ0.5です。 ただし、段階（3）で、線に沿った誤差の分布が有意水準の一様分布とは大きく異なることを示すことができる場合 、帰無仮説を棄却し、エラーが不均一に分布していると仮定します。 n行の長さごとに、ピアソンの一致基準が使用されます 観測データと帰無仮説（分布1 / n）間の対応を確立するための自由度n-1
   
   
   
   
5. ステップ（4）で推定分布と実際の分布の間に大きな不一致が見つかった場合、それらの間のオッズ比を、最後の行の効果の発現の強度の直観的な尺度として計算します（Bland and Altman（2000））。

2.2研究計画C2：最終行の影響の原因の分析

研究C1の最後の行の効果の存在を確立したので、今度は原因の特定を試みる必要があります（RQ 3）。 このために、我々は認知心理学の分野での研究の結果に基づいて、認知心理学の教授であるロルフ・ズワーンが助けてくれた初期仮説を立てました。 仮説を確認し、開発者の実践から証拠を収集するために、C1研究で見つかったマイクロクローンを作成したプログラマーにインタビューしました。 彼らのコメントと所見は、最終行の効果の存在を説明する予備バージョンを開発するのに役立ちます。 欠陥のあるマイクロクローンに関する著者が正確に確立されている人だけに回答者の輪を狭めることで、次のことが可能になります。（1）回答者が直接関係している特定の例に焦点を当てること。 （2）議論されたマイクロクローンの作成を担当したのはこれらの開発者であることが確実であるため、最も有用な回答を得るため。



図 図1は、調査の一般的な計画を示しています。 主なタスクは、マイクロクローンの作成者との連絡を確立することです（多くの場合、プロジェクトの最新バージョンには欠陥コードがありません）。 計画には4つの主要な段階が含まれます。

1. マイクロクローンのプロジェクトと例はランダムに選択されます。C2研究の作業は面倒なプロセスであり、例の著者との連絡を確立し、個々の調査を実施する必要があるためです。 「コールドコール」に対するレスポンダーの標準的な割合は30％であるという事実に基づいて、認知心理学の観点から最終ライン効果の存在を説明する初期仮説を策定するのに十分な情報を与える3つの成功した投票を当てにできます。 各マイクロクローンを分析するときは、このプロジェクトで採用されている開発ルールに精通し、リポジトリを調査する必要があります。
   
   
   
   
2. 次に、プロジェクトのソースツリーでマイクロクローンを見つけます。 エラーの多くは以前の観測結果の公開後に修正され、現在のブランチには存在しないため、この段階ではさまざまな検索戦略の適用を余儀なくされています。 まず、C1調査が実施された日からリポジトリを調査します。 失敗した場合-たとえば、マイクロクローンに隣接するコードがリファクタリングされた場合（または変更の履歴が上書きされた場合）-プロジェクトのバグトラッカーで検索を使用して、修正が行われたコミットを見つけます。 この手順でも結果が得られない場合は、すべてのプロジェクトコミットに対してフルテキスト検索（agツールを使用）を使用します。
   
   
   
   
3. オリジナルのマイクロクローンが発見されたら、git blameツールを使用してその履歴をトレースし、行われた修正に関する情報を取得し、このコードの作成者を確立します。
   
   
   
   
4. 最後に、git blame -eコマンドを使用して開発者の電子メールアドレスを見つけます。 回答者の割合を高めるために、インターネットを検索して回答者に関する追加情報を収集します。これにより、メールアドレスの関連性を判断できます。 最も正直な回答を得るために、回答者に個人データを開示しないことを保証します。 次に、各開発者に、作成者のマイクロクローンのテキスト、変更/修正の履歴、エラーのコンテキスト、および調査の理由の説明と付録を記載した電子メールを送信します。

図 1-調査計画C2

2.3調査対象

他の研究者による研究の再現を促進するために、私たちはよく知られたオープンソースプロジェクトを好みました。 C1の調査で調査した219のプロジェクトのうち、Audacityオーディオエディター（1例）、Chromium（9）およびFirefox（9）Webブラウザー、libxml（1）XMLライブラリー、MySQLデータベースなどの有名なプロジェクトで誤ったマイクロクローンが見つかりました（1）およびMongoDB（1）、C clang（14）言語コンパイラー、Quake III（3）およびUnreal 4（25）FPSシューティング、Blender（4）コンピューターグラフィックス作成用パッケージ、3次元モデリングおよび視覚化VTK用プログラム（ 8）、ネットワークプロトコルSamba（4）およびOpenSSL（2）、ビデオエディターVirtualDub（3）、およびプログラミング言語PHP（1）。 C2を研究するために、Chromium、libjingle、Mesa 3D、およびLibreOfficeプロジェクトから10個のマイクロクローンを選択しました。

2.4研究再現ノート

他の研究者の作業を容易にするために、すべての初期データと診断を含む特別なパッケージを用意しました。 これには、2つのディレクトリにグループ化されたすべてのフィルタリングされていないPVS-Studioメッセージが含まれます。findings_old /には 、プログラム可視性に関する国際会議（ICC）（Beller et al.2015）の記事で使用された古いデータが含まれますこの記事で使用されるデータ。 さらに、パッケージには、当社が分析し、プロジェクトごとに分類されたマイクロクローン（ analyze_data.csv ）、データ評価付きのスプレッドシート（ evaluation.ods ）、および研究C1およびC2のリポジトリーの分析結果が含まれます。 また、この記事の結果と図を再現するRスクリプトを追加しました。 最後に、パッケージには、回答者への質問を含むアンケートテンプレートが含まれています。

3マイクロクローンの検出方法

このセクションでは、重複するコードフラグメントを検出する従来の方法を調べ、それらがマイクロクローンの検索に適さない理由を説明し、独自の静的分析診断を使用してこの問題を回避する方法を示します。 さらに、マイクロクローンの元のセクションとコピーがどのように決定され、コミットのサイズがどのように考慮されたかを示します。

3.1最新のコードクローン検出ツールが私たちのタスクに適さない理由

例1と2が示すように、この記事のフレームワークで検討されるコードフラグメントは、テキスト内で完全に一致するか、「変数、型、または関数の識別子のみが異なる同じ構文構造を持つクローン」を含みます（Koschke 2007）。 このため、これらは非常に小さいサイズ（通常は5行/命令未満）のタイプ 1 または 2のクローンです。これらをマイクロクローンと呼びます。



重複コードを検出する従来の方法は、トークン、コード行、抽象構文ツリー（ASD）のノード、またはグラフ（Koschke 2007）を比較することです。 ただし、実際には、これらのアプローチのいずれかで、偽陽性の割合を減らすために、任意の測定単位（トークン、命令、文字列、またはASDノード）で最小クローンサイズを決定する必要があります。 原則として、この値は5-10単位の領域で取得され（Bellon et al。2007; Juergens et al。2009）、これは検討中のマイクロクローンのサイズ（2-5単位）よりもはるかに大きく、それらを検索することはできません。



そのため、例1では、行1〜3はマイクロクローンのクラスを表します。 3つの行があるため、この例ではこのクラスを3回繰り返して示します。 同様に、各インスタンスは変数、割り当て操作、割り当てられたオブジェクト、およびそのフィールドで構成されているため、長さは4ユニットです。

3.2欠陥のあるマイクロクローンの検出に使用される方法

実際には、従来の検索方法ではマイクロクローンを確実に検出できないため、独自のアプローチを使用しました。 私たちのタスクは、マイクロクローンを検出することではなく、エラーを含むマイクロクローンのみを検出することです。 この追加の制限を考えると、通常の文字ごとの一致に基づいてマイクロクローンを検出する強力な診断のセット全体を開発することができました。 これらの診断は、小さなフラグメントのコピーに起因する可能性が最も高いコードの欠陥セクションを見つけることができます。 表の中。 表1に、この調査の一部としてマイクロクローンエラーを検出した12個の診断すべてをリストして説明します。 最後の列は、このタイプの警告の総数に対する単一および複数行クローンの数の比率を示しています。 たとえば、V501の診断では、一部の論理演算子のオペランドが同一であるかどうかのみが判断されます。 答えが「はい」である場合、最良の場合、それは将来、最悪の場合にはプログラムのサポートを複雑にする可能性のある余分なコードです-本当の間違い。 他の診断法は、V501ほどマイクロクローンに関して高度に専門化されていません。 526個の警告をそれぞれ調査し、実際のマイクロクローンの272ケースのみを調査対象として選択しました。 テーブルから。 1また、マイクロクローンの78％が1つの診断（V501）によって検出され、3％の非常に低い偽陽性率であることがわかります。 他の診断は、マイクロクローンではないコードのセクションで動作する可能性が高くなります。

表1-PVS-Studioで検出されたエラーの種類と219のオープンプロジェクト間のエラーの分布

3.3誤ったマイクロクローンの起源の確立方法

質問RQ 3に答えて、最終行の効果の存在の理由を適切に議論するために、マイクロクローンの各クラスで、コードの元のコピーと、そこからコピーされたと思われるコピーも見つけました。 このような経験的分析では、コピー手順がその方向に進んだという100％の確実性は得られませんが、少なくとも一部の開発者がこの方法でコードを機械的に複製するという十分な証拠があります（RQ 3を参照）。 ほとんどの場合、マイクロクローンの2つのコピーのうちどちらがオリジナルで、どちらがコピーであるかをすぐに判断できます。 したがって、例1では、エラーを含む行3には行2からのコードのトレースが含まれており、これは行2（元）の行3（コピー）への影響を意味します。 元の行とコピーの同様の自然なシーケンスは、ほとんどのマイクロクローンで観察されます-たとえば、例1の変数x、y、zのシーケンス、または数値のように、辞書式順序であっても：



例3



Cmake

例1および3のように、元のコピーとコピーの自然な配置が明示的に表現されていない場合でも、例2のようにコンテキストによって復元できます。2行目にport_strを配置し、2行目にホストを配置するのは順序に反します。これらの変数が事前に定義されている場合、最初の命令ホストを意味します！= buzz :: STR_EMPTYがオリジナルで、2番目がコピーです。



考慮された例でコピーの起源を確立するプロセスでは、2つの問題が発生します。つまり、1）コピーされた領域のサイズは変化する可能性があります。 2）重複の長さが4を超えるマイクロクローンは、少ない例で表されます。 ただし、異なるサイズのマイクロクローンのデータを一般化できるように、各マイクロクローンiについて計算します それは私たちに遠隔性の程度を与えます 。



遠隔度1は、例4のように、直前の行/命令からコピーすることを示します。値0：マイクロクローンの同じ行でエラーが発生しました。 値-1は、コピーの逆順を示します。2番目のユニットから最初のユニットへ：



例4



UnrealEngine4

この例の1行目では、 cy（）の代わりにcx（）。IsRelativeを期待するのが自然です。IsRelativeは、2行目のコピーの可能性を示しています。 同様の名前の変数を使用するロジック、および3行目と4行目の順序は、コピーが最初の行でreturn cx（）。IsRelative（）で始まることを示しています。



ここから、遠隔の度合いを取得します または 、複製されたセクションの合計サイズに関係なく、1行または2つの隣接する複製の2つの複製がすぐ近くにあることを示します。

3.4コミットサイズの考慮方法

欠陥のあるマイクロクローンを含む各コミットのサイズと残りのコミットのサイズの比率を計算して表示するには、まずリポジトリ内の各コミットの変動性を計算します。 これを行うには、 git logツールを使用します 。これにより、リポジトリ内のすべてのコミット（マージを除く）の順序付きグラフを作成し、各コミットで追加および削除されたコードの行数を明らかにできます。 これらの数値の合計は、変更された行の合計数を示します。 各コミットのボラティリティの量。 次に、欠陥のあるマイクロクローンを含むコミットの変動性を、残りのコミットでのこのパラメーターの分布、特に中央値と比較します。 サンプル（10個のサンプル）は信頼できる統計分析には小さすぎますが、このアプローチでは、コミットサイズの違いについて合理的な結論を出すことができます。 誤った分布を扱っているため、中央値を使用します（たとえば、平均値ではありません）。 中央値は独立した実際の意味であり、他の同様の意味と比較します。

4件

このセクションでは、例を調べて統計的評価を実施することにより、欠陥のあるマイクロクローンをより詳細に調査します。

4.1結果の一般的な説明

表の中。 2主な統計は、研究C2の結果に従って収集されます。 2011年半ばから2015年7月までの期間、219のオープンプロジェクトでPVS-Studio診断のフルセットを使用しました。 ソフトウェア開発のコンサルティングを専門とするAndrey Karpovは、特定の各プロジェクトの検証時に利用可能な最新バージョンのPVS-Studioを使用して、これらすべてのプロジェクトの分析を行いました。 彼は、コードの潜在的な欠陥を示す合計1,891の警告を残して、誤検知を除外しました。 これらの警告は162の診断によってグループ化されました。 次に、各メッセージを調べて、そのうちの272が12の診断によって発行され、マイクロクローンに関連していることを発見しました。 9つのケースでメッセージが複製されたため、最終的に263個のマイクロクローンが残りました。 プロジェクトレベルでの統計分析は、選択したプロジェクトの半分で診断が欠陥クローンを認識できたことを示しています。 これらのケースのほとんどすべて（92％）には、最後の行の効果を持つ少なくとも1つの例が含まれています。

表2-調査結果の統計



タブ。 3には、263個のマイクロクローンで検出されたエラーの概要が含まれています。 合計で、複数行のクローンの74％には最後の行にエラーが含まれ、90％の単一行のクローンには最後の命令が含まれます。

表3-調査結果の要約

4.2結果の詳細分析

マイクロクローンの検出に使用した診断の原理をより完全に理解するために、以下では、マイクロクローンに関連する263のPVS-Studio警告の最も明らかな例をいくつか見て、表から最も一般的なエラーを特定します。 1。

4.2.1 V501-等しい部分式

表からわかるように。 1、ほとんどのマイクロクローン警告はV501診断によって発行されました。 以下は、Chromiumブラウザからのこのようなエラーの典型的な例です。



例5



クロム

これは1行のマイクロクローンで、2番目と3番目の部分式は完全に同一ですが、同時に論理演算子OR（ || ）で接続されているため、式が冗長になります。 実際、姓（ NAME_LAST ）を確認する必要がありました。これは、この3つのユニットのブロックの最後の行効果です。

4.2.2 V517-同一の条件式

Diagnostics V517は、ifステートメントの2つのブランチに対して同じ条件を検出します。



実施例6



linux-3.18.1

行9の3番目のマイクロクローンの後のelse ifステートメントの本体はデッドコードです。これは、実行のスレッドが到達しないためです。 スロット値が0の場合は、最初の条件ですでに処理されます。

4.2.3 V519-変数に同じ値を割り当てる

(, , , , ), , . MTASA m_ucRed , m_ucBlue .



7



MTASA

V519 «» , , 8:



8



linux-3.18.10

f->fmt.vbi.samples_per_line , . , , 1 . , , (, , ) - . Release: , , .

4.2.4 V523 —

if- , , Haiku :



9



Haiku

, , else mpa_size - . , 3 , « », .

4.2.5 V524 —

. 10 5 PerPtrBottomUp.clear() . , 。



10



Clang

4.2.6 V537 —

V537, , Quake III. PVS-Studio rectf.X :



11



Quake III

(.. ) y- rectf.X .

4.2.7 V656 —

V656 , . , . , , , , . , V656, LibreOffice.



12



LibreOffice

maSelection.Max() aSelection , .

4.2.8

12, . Chromium — 12 , (. . 4):



13



Chromium

2 data_[M02] , :

4 — ?? 2

4.3

. 4 158 , . 5 — 105 . . , 2 . , , .

5 —



. 4 5 p = 0,05, , . p-, , . 2-6 . 4 2-4 . 5。



RQ1 RQ2, p- 2, 3, 4, 5 6 2, 3 4 (p < 0,05). , / . . , , , . . 4 5.



: « /» « /» (. . 3). , , 1, , . . 4, 2, 4 5 ( ) . , 2, : 9,5 , . 72 , .



, , /, RQ 1 RQ 2.

4.4

, , , . RQ 3 :

• RQ 3 ?

, .



. 6 . , . , 263 245.

6 — ( ) ( )



図 2 . , 165 245 (67%) . — 18 %, (9%) (3%). 4% . , , , . , : , . 117 /, , 33 (28%). 4,9 , , 20% , . 28% , , . , , .

図 2 — () ()



図 2 , (. 3.3). , 84% (220 245), ..



89% (195 220) または 。 , . , .. (3 220). , , , 81% (66 81). , :

1. . , .
2. , . , .

4.5

C2 , . . , :

1. (.. ).
2. .
3. , .
4. .

. 7 , . Skype. , , , , . I1-I7 ID- . , , - . . I1, I2, I4, I6 I7 . , .

7 — 6.10.2016



, . , , , . 7b37fbb I1 , ( . 7 ), , ( 6b7fcb4 ).



I1 :



14



I1

, -, , !has_mic !has_audio . , , . , « - », , « , ». , - , , , !a && !a .



I4 , , , , :



15



I4

, field.type == trans(«string») ||, , :



16



I4

, « , ». , , , -. (. 3.3), , , . , . I4 , , « ». I1, , .



I6 , « , [...] , ». , « ». , I6 -, . « ». , , « , ». I6 , , « , ». , «», . « . -. , [...], ».



I7 :



17



I7

彼の記憶によると、彼は「コピー＆ペーストを使わずにこの行を入力しただけ」で、「明らかに急いでコードを注意深く読んでいたようだ」というエラーを逃しました。 回答者は、このコミットの作成の正確な日付を思い出すことができませんでしたが、彼は「ほとんど常に多くの仕事があります」と述べました。



アンケートの結果から、コミットのサイズは、欠陥のあるマイクロクローンが回答者が言及したさまざまな手段と保護メカニズムによる検出を回避する可能性が高い要因の1つであると結論付けることができます。 この仮定が正しい場合、そのようなマイクロクローンを運ぶコミットは異常に大きくなるはずです。 「異常に大きい」の定義は相対的な値を示し、リポジトリ内のコミットを比較する場合にのみ意味があります。 このことを念頭に置いて、マイクロクローンに欠陥があるコミットのサイズを、各プロジェクトのコミットのサイズの中央値と比較しました。これを図に示します。 3.得られたデータは、すべての場合において、欠陥のあるマイクロクローンを含むコミットのサイズが中央値よりも数桁大きいことを示しています。

図 3-リポジトリの履歴全体のコミットのサイズの中央値（青い破線）および欠陥のあるマイクロクローンを含むコミットのサイズ（対数スケールでの変動の大きさで表される）（オレンジの破線）

4.6結果の有用性

オープンソースプロジェクトで多くの潜在的なエラーを発見したので、オープンソース開発者のコ​​ミュニティを支援し、著者がそれらを修正するのに十分重要なエラーを見つけたかどうかをチェックしたかった。 これを行うために、プロジェクトバグトラッカーにコメントを投稿しました。 その結果、メッセージの多くが考慮され、プロジェクトコードの品質が向上しました。 そのため、例2（Chromiumプロジェクト）の検証エラーが修正されました。 検索クエリpvs-studioバグ| この問題は、Firefox、libxml、MySQL、Clang、samba、および他の多くのプロジェクトでの多数の編集に関するメッセージを発行します。これは、調査の結果によって促進されました。 たとえば、2016年10月11日のcaff670 コミットで、 2005年以降にSambaコードに存在していた欠陥のあるマイクロクローンを修正した場合です。

5調査結果の分析

このセクションでは、エラーパターンについて収集した情報と、エラーの根底にある心理的メカニズムに関するデータを組み合わせます。 結論として、結論の妥当性を脅かす可能性のある要因を検討します。

5.1最終行の効果の技術的な複雑さおよびその他の技術的理由

最終行の影響の技術的な理由として、他の行と比較して最終行の技術的な複雑さが高く、その結果、エラーの素因が大きくなる可能性があります。 たとえば、コンパイラはチェック時に最後の行をスキップするか、コードがIDEウィンドウに書き込まれ、マイクロクローンの最後の行が現在のコードエディタウィンドウの最後の行でもあるときにチェックに失敗する場合があります。 ただし、次の理由により、これらの考慮事項は正しくありません。

1. 原則として、最新のIDEは構文のチェックが遅れる傾向はありません。
2. マイクロクローンの最後の行または命令は、構文に関して正しいです。 コンパイラーは、問題にプログラマーの注意を引く警告を発行できません。

一方、IDEに診断を含めると、マイクロクローンを検出するコンパイラーを使用すると、エラーがコミットされる前に見つけやすくなります。



別の技術的な理由は、いくつかの命令のシーケンスでは、最後の命令を他の命令よりも作成するのが難しいという事実に関連している可能性があります。 ただし、例1、2、5、7、および11が示すように、逆のことが当てはまります。すべての複製は1つのテンプレートに従って作成されるため、最初のテンプレートのみが最大の難易度を持ちます。 オリジナル、それ以降はすべてコピーのみです。

5.2心理的メカニズムと原因

最後の行の効果の存在は技術的な理由によるものであるとは疑わしいので、その根底にあるかもしれない心理的メカニズムを考慮すべきです。 相談のために、認知心理学の教授（この記事の4番目の著者）に目を向けて、彼に私たちの観察結果を提示しました。 この段階では、より徹底的な研究には心理実験が必要になるため、結論は予備的なものであり、欠陥のある重複の原因の分析から再構築できないミスを犯すプロセスを直接観察することができます（セクション3.3を参照）および回答者の回想（参照。セクション4.5）。



認知心理学では、一連のアクションのエラーは、日常的な操作中に発生するエラーです。 このタイプのエラーは、専門家によって広範に研究されてきました（Anderson 1990）。 このような間違いの典型的な例は、牛乳を1回注いでから砂糖を入れる代わりに、コーヒーに2回牛乳を加えた場合です。 マイクロクローンの起源の分析結果が示すように、開発者はコードをコピーする際にさまざまな機械的手法とアルゴリズムの兵器庫を使用します。 次のアルゴリズムのいずれか：「[元のフラグメントを書き込む]、[元のコピー]、[元のコピー]、...、[コピーの編集]、[コピーの編集]、...」（投票I4、I6を参照）。 それとともに、アルゴリズムが適用されます：「[元のフラグメントを書き込む]、[元のコピー、コピーを編集]、[元のコピー、コピーを編集]、...」極端な場合、データセットでは、このアルゴリズムは最大34回繰り返されるようです。 マイクロクローンを作成するとき、さまざまな方法が使用されるという事実にもかかわらず、それらはすべて、自動操作と意識的操作の異なる比率を持つ一連のアクションになります。 したがって、認知心理学の観点から見ると、開発者がマイクロクローンで行ったエラーは、一連のアクションの典型的なエラーです。



詳細には違いがありますが、すべてのシーケンスモデルは、この種のエラーの主な原因は明らかに認知ノイズであることに同意しています（Botvinick and Plaut 2004; Cooper and Shallice 2006; Trafton et al.2011）。 この場合、ノイズとは、現在のタスクに関係のない表現を意味し、プログラマの注意をそらします。 ノイズは、タスクのタイミングの制限などの外部要因、または大規模なコミットなどの内部要因によって引き起こされるストレスによって生成される可能性があります。 シーケンス制御モデルは、最後の行の効果の根底にある可能性のある心理的メカニズムについて推測することを可能にする有用な理論的基礎を提供します。 この段階では、マイクロクローンの特定の例とコード内でのそれらの位置に関する情報しかありませんが、それらの発生の詳細はわかりません。 それでも、セクション4.4に示すように、インタビューした開発者の回答とマイクロクローンの起源の分析結果により、マイクロクローンの表示方法について合理的な結論を導き出すことができます。 コピーと編集は、コードを書くときにプログラマーによって実行される主な操作です。 例1をもう一度見てみましょう。ここでの編集操作は、変数名の編集と値の編集という2つの小さなステップで構成されています。



例1



トリニティコア

エラーは3行目にあります。この行は2行目をコピーすることで作成されたようです。最初の置換は成功しました（変数名はyからzに変更されました）が、2番目のステップ（値の編集）はスキップされ、エラーになりました。 理論的には、このコードは、行1を二重にコピーし、結果の複製を編集することで作成できます。 ただし、3行目のxの代わりに変数名yを使用すると、2行目がコピーされたと考える理由がわかります。 セクション4.4に示すように、2行より長いほとんどのマイクロクローンでは、通常、前の行がコピーされます。 そのような場合、アルゴリズムが使用されたことになります：「[コピー、編集、編集]、[コピー、編集、編集]、...」



シーケンス制御モデルによると、このタイプのエラーは認知ノイズが原因で発生します。これは、同じタイプの一連の操作の終わり近くで発生する可能性が最も高いです。プログラマーの注意が、たとえば新しいコードの作成など、次のタスクに時期尚早に切り替わるためです（ポーリングI6を参照）。 既に述べたように、認知ノイズの原因を説明するわずかに異なるバージョンがいくつかあります。 例として、間違ったアクションプランを選択して、最後の行の効果を説明するバージョン（Cooper and Shallice 2006）を提供します（たとえば、開発者は現在のフラグメントの完成に集中するのではなく、すでに次の行に移動しています）。



インタビューしたプログラマーの誰も、マイクロクローンの作成中に過度に高いレベルのストレスを訴えたことはありませんでしたが、回答者I6とI7の証言は他とは異なります：彼らは一般に高い作業負荷とコードを書くことでより速く前進したいという欲求を指摘しました 表に従って、欠陥マイクロクローンを含むコミットを作成するための現地時間の分析 7は、必須の勤務時間中に作成されたのはそのうち2つだけであり、残りのプログラマーは勤務時間外にコードを作成しましたが、勤務中に作成したことを示しています。 疲労は脳のパフォーマンスを低下させ、短期記憶に悪影響を与えることが知られています（Kane et al。2007）。 おそらく疲労と速攻は、欠陥のあるマイクロクローンの出現に重要な役割を果たします。



さらに、欠陥のあるマイクロクローンを含むすべてのコミット（リファクタリングを含む）のサイズが非常に大きく、リポジトリのコミットの標準サイズよりも桁違いに大きいことがわかりました。 これは、コミットのサイズが認知的ノイズを引き起こす重要な要因ではないにしても、重要であるという考えに私たちを導きます。そのため、エラーは気付かれません。 この結論は、短期記憶のオーバーロードに関するバージョンと、最終コードを大量に制御することは非常に難しいという回答者I1の発言とよく一致しています。



世論調査の結果から、短命の欠陥のあるマイクロクローンはソフトウェア開発の分野で広まっている現象であることがわかりますが、それらは通常、初期段階で、または少なくとも独立して、または同僚の助けを借りて行われたコードをレビューするプロセスで検出されます（Beller et al.2014） したがって、残りの修正されていないマイクロクローンで観察された認知エラーは、プログラミングエラーだけでなく、レビューエラー（Healy 1980）でもあり、コードのレビュー中に開発者が最後の行や他の行の欠陥に気付かないという事実に基づいています。 実際、私たちの世論調査では、明らかに、コミットでキャッチされたマイクロクローンで、そのようなエラーが2回行われたことを示しています。1回は作者によるコードのレビュー時で、もう1回は同僚によるコードの削除時です。 前の行よりも高い確率で最後の行にエラーが表示されるのは、おそらく、シーケンスエラーであるためです。 人は、現在のタスク（レビュー）を完了する時間を持たずに、次のタスク（たとえば、コードの次の部分を書く）に精神的に切り替えます。 別の説明では、次の同様の指示が連続して行われているため、エラーは目立たないことを示唆しています。 さらに、元のコピーとコピーの視覚的な類似性により、個々の行を認識しにくくなる可能性があります。 コードレビューの問題に関する研究は、フラグメントの類似性（単語の繰り返しの頻度に現れる）により、レビュー担当者が校正に費やす時間が少なくなり、テキストのエラーを認識する能力に悪影響を与えることを示しています（Moravcsik and Healy 1995）。



最後の行の効果の発現のすべての潜在的な要因は、認知ノイズのためにプログラマの注意の量が減少する状況で、この種の間違いを犯す可能性の増加に関連付けられています。 その発生の考えられる原因は、主に大規模なコミット、重いワークロード、ストレス、注意散漫、疲労に関連している可能性があります（O'Malley and Gallas 1977）。 逆に、私たちの観察は、外部ノイズへの応答を制御する開発者の能力（Fukuda and Vogel 2009）、すなわち タスクに集中できるかどうかは、シーケンスエラーのあるマイクロクローンの可能性に大きく影響します。

5.3研究結果の妥当性を脅かす要因

このセクションでは、結果の妥当性に対する内部および外部の脅威を検討し、それらの影響を最小限に抑える方法も示します。

5.3.1内部要因

主な内部要因の1つは、エラーがどの行にあるかを正しく判断することです。 したがって、例2では、​​2つの命令のいずれもコピーとして取得できます。 ただし、コードの読み書きは通常、上から下、左から右に行われます（Siegmund et al。2014）。 したがって、行と命令のエラーの配置が同じ順序に従うことを考えるのは自然であり、単に正しいでしょう：例2では、​​2番目の命令がそれを読み取ることによってのみ最初の命令のコピーであることが理解できるため、2番目の命令を欠陥としてマークします。 さらに、多くの場合、この例のように、最も近いマイクロクローンコンテキスト（例2では、 ホスト変数が最初に宣言され、次にport_strが宣言されます）は、プログラムテキストの残りの自然な順序を設定します（最初にホストをチェックし、3行目のport_strをチェックします ） 。 研究者のバイアスの潜在的な影響を最小限に抑えるために、データは最初の2人の著者間で独立した処理のために配布され、論争のあるケースが共同で議論されました。 結果について合意に至らなかった場合、却下されました。 作業の過程で、以前の研究（Beller et al。2015）の202の結果すべてを再分類し、以前の調査結果とほぼ完全に一致していることを発見しました。 このような状況で欠陥ラインをマークする手順は詳細に規定されているため、各専門家の推定値間の高度な相互合意に自信があり、これにより研究の再現性が保証されます。



診断では、すべての欠陥マイクロクローンが検出されない可能性があります。 この要因は、この種のエラーをすべて検出するとは主張していないため、わずかな脅威です。 診断の数を12に増やすことで、ほとんどのマイクロクローンを見つけることができたと考えています（表1を参照）。 これは、V501、V517、V519、およびV537、いくつかの主要な診断でほとんどのエラーが検出されたという事実によって確認されます。 van TonderとLe Guが診断の短縮セットを使用して24,000を超える誤ったマイクロクローンを発見したという事実（van Tonder and Le Goues 2016）。



元のコピーとコピーの正しい定義に対する自信にもかかわらず、コピーが開発者によってどのように作成および編集されたかはわかりません。 リポジトリの実証分析は、コードのブロックを上から下へ、および個々の行を左から右へ読み取る順序に基づいています。 開発者はコードを読みながらコードのさまざまな部分を「スキップ」し、現在の問題の解決に関連すると思われるブロックのみに特別な注意を払っていることを知っています（Busjahn et al。2015; Siegmund et al。2014）。 同時に、制御フローの移動方向にコードを読み取るだけで、マイクロクローンである小さな論理的に接続されたフラグメントを理解することができます。 上から下へ、左から右へ。 特に、次の質問への回答に興味があります。1）ホットキーシーケンス「ctrl + c、ctrl + v」が何回使用されましたか？ 2）マイクロクローンはどの順序で作成されますか？ 3）プログラマーは、コードをサポートする過程でマイクロクローンをどの順序で読み取り、編集しますか？ これらの質問に答えるには、WatchDogプラグインが行う方法と同様に、プログラマーの作業を「現場」で観察できる調査を実施する必要があります（Beller et al。2015、2015、2016）。 この目的のために、CloneBoardツールの個々のコンポーネントを使用できます。このツールは、Eclipseですべての切り取り、コピー、貼り付け操作を記録します（de Wit et al。2009）。



これらの制限を考えると、この段階での最後の行の効果の心理的基礎に関する我々の結論は議論の余地があるかもしれません。 より徹底的な分析を行うには、エラーを作成するプロセスを生体内で調査できる心理実験が必要です。 選択した研究方法の特性により、マイクロクローン作成の特定の手順を逃したリスクがあります。 それにもかかわらず、私たちの回答者は比較的少数のそのような断片を作成するのに時間がかかると指摘したので、実験室条件下で欠陥のあるマイクロクローンが出現する状況を再現することは非常に問題だと考えています。 , , , (Adair 1984), , . , , , , .

5.3.2

, PVS-Studio C C++. C — (Meyerovich and Rabkin 2013), , , , C C++ . , , : , if-, (. 1, 2, 5, 7 11). , C: Java, JavaScript, C#, PHP, Ruby Python. , ?1,2 , (. . 2). , PVS-Studio, , , , , . : , .

6

« », (Roy . 2014). : « — , - » (Baxter . (1998)) « — [...] , » (Basit and Jarzabek (2007)). , , . , (Koschke 2007). 1 , 2 ( ). 3 , 4 (Roy . 2014). , . (Koschke 2007; Balazinska . 1999; Kapser and Godfrey 2003). : , , « », . .



. 2007 . C Java (Bellon . 2007). 25 . 2014 , (Svajlenko and Roy 2014). 50 , 15 15 (Svajlenko and Roy 2014). . , , . .



(Beller . 2015) 380 125 Java (van Tonder and Le Goues 2016) 24 304 , , . 43 , . , .



, , , 9% 17% (Zibran . 2011), 1, 2 3 (Koschke 2007). « » 5% (Roy and Cordy 2007) 50% (Rieger . 2004; Roy . 2014). , , , . , — , « ». , , , . (Chatterji . 2011; Gode and Koschke 2011; Inoue . 2012; Xie . 2013).

7

, .



, , . , , . . , , . IDE: .



, , , , , . .



219 , 263 . , — . . , , — , .



, , , - , . , - . , , - . , -, , .



, , , , . , , , , . , ; , - , , . PVS-Studio , , , .

注釈

1. TrinityCore — - (MMOG), www . trinitycore . org .
2. Chromium — Google Chrome, www.chromium.org .
3. http://www.viva64.com/ru/b/0260
4. www.reddit.com/r/programming/comments/270orx/the_last_line_effect
5. http://www.viva64.com/ru/pvs-studio-download
6. 10.6084/m9.figshare.1313697
7. . , .
8. : http://viva64.com/ru/d/0368/ .
9. https :// codereview . chromium . org /7031055
10. www . google . com / search ? q = pvs - studio + bug +|+ issue
11. https :// bugzilla . samba . org / show _ bug . cgi ? id =12373
12. Clang . : https :// llvm . org / bugs / show _ bug . cgi ? id =9952 .

謝辞

ICSE'15 «Mercato Centrale», , .

, 2016





Creative Commons Attribution 4.0 International , , , , Creative Commons , .