LLVM / Clangコードベースから学んだ教訓

翻訳者から：私があなたに注目した記事で、著者は、CppDependコード分析ツールを使用してLLVM / Clangコードベースを調べました。



ClangがGCCおよびMicrosoftのコンパイラと同じくらい成熟したCおよびC ++コンパイラであることが証明されましたが、Clangが特別なのは、それが単なるコンパイラではないことです。 これは、ツールを作成するためのインフラストラクチャです。 そのアーキテクチャはライブラリの使用に基づいているため、プロジェクトへの機能の再利用と統合がよりシンプルで柔軟になります。

クラン構造

他の多くのコンパイラと同様に、Clangには3つのフェーズがあります。



ソースコードを解析し、エラーをチェックし、入力コードを表す言語依存の抽象構文ツリー（AST）を構築するフロントエンド。

オプティマイザー：その目的は、フロントエンドによって生成されたASTを最適化することです。

バックエンド：ターゲットマシンに応じて、マシンによって実行される最終コードを生成します。

Clangと他のコンパイラの違いは何ですか？

最大の違いは、ClangはLLVMに基づいており、LLVMの主なアイデアは中間表現（IR）を使用することです。これはJavaのバイトコードの一種です。



LLVM IRは、コンパイラーの最適化段階にある分析と変換の中間段階をサポートするように設計されています。 「軽量」ランタイム最適化のサポート、手続き間/機能間の最適化、プログラム全体の分析、積極的な構造変換など、多くの特定の要件を考慮して開発されました。 ただし、最も重要な側面は、中間表現自体が明確に定義されたセマンティクスを持つ一流の言語であることです。



この構造により、ほとんどのコンパイラを再利用して他のコンパイラを作成できます。たとえば、フロントエンドを置き換えて他の言語をサポートできます。







この強力なおもちゃの中に入り、それがどのように設計および実装されているかを見るのは非常に興味深いです。 C ++開発者は、このコードベースから多くの優れた実践を学ぶことができます。



CppDependとCQLinqを使用してソースコードをX線撮影し、開発者の決定事項を理解しましょう。

1.モジュール性

1.1。 モジュール性とライブラリの使用

clangの開発における主な概念は、ライブラリの使用です。 フロントエンドのさまざまな部分は、さまざまな目的で共有できるさまざまなライブラリに明示的に分割できます。 このアプローチにより、優れたインターフェイスの使用が促進され、新しい開発者がタスクを簡単に行えるようになります（全体像のごく一部しか理解する必要がないため）。



依存関係構造マトリックスであるDSM（Dependency Structure Matrix）は、コンポーネント間の依存関係を表すコンパクトな方法です。 空でない行列セルには数値が含まれています。 この数値は、セルで表される結合強度を表します。 関係の強さは、関係に含まれるメンバー/メソッド/フィールド/タイプおよび名前空間の数として表すことができます。







この依存関係グラフは、clangが直接使用するライブラリを示しています。







ご覧のとおり、clangBasic / clangFrontEnd、clangBasic / clangDriver、clangBasic / clangLexライブラリの間に3つの循環依存関係があります。 コードが読みやすく、保守しやすいように、ライブラリ間の循環依存関係を削除することをお勧めします。



clangFrontendがclangBasicライブラリを使用しているのはなぜですか？







1つの列挙フィールドのみが循環依存関係を引き起こし、コードをリファクタリングでき、依存関係を簡単に修正できます。

1-2名前空間を使用したモジュール性

C ++では、名前空間はコードをモジュール化するために使用され、LLVM / clangでは3つの主な理由で使用されます。



次のCQLinqクエリに示すように、多くの名前空間には列挙のみが含まれています。







大規模なプロジェクトでは、2つの異なる列挙に同じ名前が付けられないことは保証できません。 この問題は、列挙値とともに列挙値を使用することを暗示する列挙クラスを使用して、C ++ 11で解決されました。 コードは、C ++ 11列挙クラスを使用して近い将来リファクタリングされる可能性があります。



匿名の名前空間：名前のない名前空間。グローバルな静的変数の作成を回避します。 作成した匿名名前空間は、作成されたファイルでのみ使用できます。 以下は、使用されているすべての匿名名前空間のリストです。







すべての非匿名名前空間：







名前空間は、アプリケーションをモジュール化するための優れたソリューションです。LLVM/ clangは、500以上の名前空間を定義して、コードを読みやすく保守しやすいようにするモジュール性を提供します。

2.パラダイムの使用

C ++は単なるオブジェクト指向言語ではありません。 Bjarn Straustrupは、C ++はマルチパラダイム言語であることを指摘しました。 多くのプログラミングスタイルまたはパラダイムをサポートし、オブジェクト指向はそれらの1つにすぎません。 その他は、手続き型プログラミングと汎用プログラミングです。

2.1。 手続き型プログラミング

2.1.1。 グローバル機能



LLVM / Clangソースで定義されているすべてのグローバル関数を検索します。







これらの機能は3つのカテゴリに分類できます。



1-ユーティリティ：たとえば、あるタイプから別のタイプへの変換関数。







2-演算子：CQLinqの結果が示すように、多くの演算子が定義されています：







llvm / clangソースコードでは、ほとんどすべてのオーバーライドされた演算子が見つかります。



3-コンパイラロジックに関連する関数：コンパイラのさまざまな機能を実装する多くのグローバル関数。



おそらく、このタイプの関数は、静的クラスメソッドなどのカテゴリにグループ化するか、名前空間でグループ化する必要があります。







2.1.2。 静的グローバル関数



グローバル関数を静的として宣言することをお勧めします。ただし、別のソースファイルから呼び出す必要がある特定の場合を除きます。







ほとんどすべてのグローバル関数は静的として宣言されています。



2.1.3。 グローバル関数-静的の候補



匿名名前空間で宣言されておらず、宣言されたファイルの外部のメソッドで使用されていないグローバルなエクスポート不可能な関数は、静的関数へのリファクタリングに適しています。







ご覧のとおり、静的関数にリファクタリングできる関数はわずかです。

2.2。 オブジェクト指向のパラダイム

2.2.1。 継承



オブジェクト指向プログラミング（OOP）では、継承はオブジェクト間の「is」関係を確立する方法です。 多くの場合、既存のコードを再利用する方法と混同されますが、実装を再利用するための継承は強力な関係をもたらすため、良い方法ではありません。 コードの再利用性は、構成によって実現されます（構成は継承よりも望ましい）。 少なくとも1つの基本クラスを持つすべてのクラスを探しましょう。







このクエリではメトリックビューを使用することをお勧めします。



メトリックビューでは、コードベースはツリーマップとして表されます。 これは、ネストされた長方形を使用してツリーのようなデータ構造を表示する方法です。 CppDependで使用されるツリー構造は、通常のコード階層です。



プロジェクトには名前空間が含まれます。

名前空間にはタイプが含まれます。

タイプにはメソッドとフィールドが含まれます。



ツリーマップは、CQLinqクエリ結果を表示する便利な方法です。青い長方形は結果を表し、クエリに関連付けられたタイプを確認できます。







ご覧のとおり、継承はllvm / clangソースコードで広く使用されています。



多重継承：複数のクラスから継承されたクラスを見つけましょう。







多重継承はめったに使用されず、クラスの1％未満が複数のクラスから継承されます。



2.2.2。 仮想メソッド



ソースコードで定義されているすべての仮想メソッドを見つけましょう。







多くのメソッドは仮想であり、そのうちのいくつかは純粋な仮想です：







OOPパラダイムは、llvm / clangソースコードで広く使用されています。 一般化されたプログラミングはどうですか？

2.3。 一般的なプログラミング

C ++は、一般化されたプログラミングのアイデアをテンプレートで表現するユニークな機会を提供します。 パターンは、一般化されたアルゴリズムとデータ構造を表現できるパラメトリック多型の一形態です。 C ++テンプレートのインスタンス化メカニズムにより、一般化されたアルゴリズムとデータ構造が使用されると、特定のパラメーター専用に完全に最適化された特殊なバージョンが作成され、一般化されたアルゴリズムが非一般化バージョンと同じくらい効率的になります。



2.3.1。 ジェネリック型



ソースコードで定義されているすべてのジェネリック型を見つけましょう。







多くのタイプは一般化されたものとして定義されています。 一般化されたメソッドを見つけましょう：







メソッドの1％未満が一般化されています



したがって、llvm / clangのソースコードは3つのパラダイムを使用します。

3. PODはデータモデルを定義します

オブジェクト指向プログラミングでは、Plain Old Data（POD）は、オブジェクト指向関数を使用せずに、値の受動的なコレクションのみを表すデータ構造です。 コンピューターサイエンスでは、パッシブデータ構造とも呼ばれます。



ソースコードでPODタイプを探しましょう。







1,500を超えるタイプがPODタイプとして定義され、その多くはコンパイラデータモデルの定義に使用されます。

4. 4人のギャングを設計するパターン

設計パターンは、ソフトウェア設計の一般的な問題の解決策を説明するソフトウェアエンジニアリングの概念です。 Gang of Fourパターンが最も人気があります。 llvm / clangソースコードでそれらの使用法を見つけましょう。

4.1。 工場

ソースコードで定義されているファクトリメソッドのリスト：







抽象ファクトリーメソッドのリスト：

4.2。 オブザーバー

オブザーバーパターンは、オブジェクトにオブザーバーオブジェクトのリストが含まれ、通常はメソッドの1つを呼び出すことにより、状態の変化を自動的に通知するデザインパターンです。



ソーステキストには1人のオブザーバーしかありません。

4.3。 訪問者

訪問者パターンは、構造を歩き回り、構造の各ノードで特定のアクションを実行する必要がある場合に推奨されます。



llvm / clangソースコードでは、訪問者パターンが広く使用されています。

5.カップリングと凝集

5.1。 クラッチ

アプリケーションの一部を変更するだけで、アプリケーションの残りの部分を変更する必要が少なくなるため、低い密着度が望ましいです。 長い目で見れば、これにより、新しい機能をアプリケーションに変更したり追加したりすることに関連する時間、労力、費用を大幅に節約できます。



抽象クラスを使用するか、ジェネリック型およびメソッドを使用して、低度の結合を実現できます。



ソースコードで定義されているすべての抽象クラスを見つけましょう。







280を超える型が抽象として宣言されています。 ただし、一般的なタイプと一般的な方法を使用することで、低い接着度も達成されています。



接続性



単一責任の原則では、クラスには複数の変更理由を含めることはできません。 このようなクラスは接続と呼ばれます。 LCOM値が高い場合、ほとんどの場合、接続が不十分なクラスに対応しています。 いくつかのLCOMメトリックがあります。 LCOMは[0-1]の範囲の値を取ります。 LCOM HS（HSはHenderson-Sellersの略）は[0-2]の範囲の値を取ります。 LCOM HSの値が1より大きい場合、警告されるはずです。 LCOMメトリックは次のようにカウントされます。



LCOM = 1-（合計（MF）/ M * F）

LCOM HS =（M-合計（MF）/ F）（M-1）



ここで：



Mは、クラスメソッドの数です（静的メソッド、コンストラクター、ゲッター/セッター、イベントを追加および削除するためのメソッドをカウントします）。

Fは、クラスの非静的フィールドの数です。

MF-特定の非静的フィールドにアクセスできるクラスメソッドの数。

Sum（MF）-クラスのすべての非静的フィールドのMFの合計。



この式で表されるアイデアは次のように定式化できます：すべてのメソッドがすべての非静的フィールドを使用する場合の接続クラス、つまり合計（MF）= M * F、したがってLCOM = 0およびLCOMHS = 0







235のクラスをレビューしましたが、おそらくそれらのいくつかはリファクタリングして接続性を改善できます。

6.免疫力、純度および副作用

6.1。 不変の型

オブジェクトは、作成された時点から状態が変わらない場合、不変と呼ばれます。 したがって、インスタンスが不変である場合、クラスは不変と呼ばれます。



不変オブジェクトの使用を支持する議論が1つあります。競合するプログラミングを大幅に簡素化します。 マルチスレッドプログラミングの書き込み操作が非常に複雑な理由を考えてください。 スレッドのリソース（オブジェクトまたは他のOSリソース）へのアクセスを同期することは難しいためです。 アクセスを同期することが難しいのはなぜですか？ 複数のストリーム間で競合が発生しないことを保証するのは難しいためです。 書き込みアクセスがない場合はどうなりますか？ 言い換えれば、スレッドがアクセスできるオブジェクトの状態が変わらない場合はどうでしょうか？ その後、同期の必要はありません。



不変クラスのもう1つの利点は、それらがLisk置換の原則に決して違反しないことです。WikipediaのLisk原則の定義は次のとおりです。



「 サブクラスは、基本クラスのプロパティの新しいミューテーターを作成しないでください。基本クラスで定義されたプロパティを変更するメソッドを提供しなかった場合、このクラスのサブタイプもそのようなメソッドを作成しません。つまり、基本クラスの不変データはサブクラスで変更できません。 」



ソースコード内の不変型のリストを次に示します。

6.2。 純度と副作用

不変の型の主な利点は、副作用を排除するという事実にあります。 これについてはウェス・ダイアー以上に語ることはできません。



「私たちは皆、グローバル変数を使用するのは良い考えではないことを知っています。 これは、副作用の危険性によるものです（グローバルスコープ）。 グローバル変数を使用しない多くのプログラマーは、同じ原理がより限られた規模でフィールド、プロパティ、パラメーター、変数に適用されることを理解していません：正当な理由なしにそれらを変更しないでください（...） "



モジュールの信頼性を高める1つの方法は、副作用を取り除くことです。 これにより、モジュールのコンパイルと統合がより簡単で信頼性の高いものになります。 副作用がない場合、環境に関係なく常に同じように機能します。 これは、参照透過性と呼ばれます。



副作用のない関数とメソッドを書く-これらはオブジェクトを変更しない純粋な関数です-これはあなたのプログラムの正確さという意味でより良いでしょう。



副作用のないすべてのメソッドのリストは次のとおりです。







100,000を超えるメソッドがクリーンです。

7.実装の品質

7.1。 大きすぎる方法

多くのコード行を持つメソッドは、維持および理解が困難です。 60行以上のメソッドを見つけましょう。







llvm / clangのソースコードには100,000を超えるメソッドが含まれており、2％未満のメソッドは大きすぎると見なすことができます。

7.2。 多くのパラメータを持つメソッド

いくつかのメソッドには8つ以上のパラメーターがあります。

7.3。 多くのローカル変数を持つメソッド

メソッドの1％未満に多くのローカル変数があります。

7.4。 複雑すぎる方法

複雑な機能を検出し、コードの行数、パラメーターの数、ローカル変数の数を計算するための多くのメトリックが存在します。



複雑な機能を検出するための興味深いメトリックもあります。



循環的複雑度は、プロシージャで行われる決定の数に等しい一般的なプロシージャプログラミングメトリックです。



ネストされた深さは、メソッド本体で可視領域のネストの最大深さを決定するメソッドに対して定義されたメトリックです。



最大ネストサイクル。



これらのメトリックに許可される最大値は、開発チームの選択により大きく依存し、一般に受け入れられている標準はありません。



複雑であると考えられるメソッドを見つけましょう。







複雑さを最小限に抑えるための候補となるメソッドはわずか1.5％です。

7.5。 ハルステッドの難しさ

Halstead Complexityは、1977年にMaurice Howard Halsteadによって導入されたソフトウェアメトリックです。 Halsteadは、プラットフォームに関係なく、プログラムメトリックがさまざまな言語でのアルゴリズムの実装を反映する必要があるという観察を行いました。 これらのメトリックは、コードによって静的に計算されます。



Halsteadは多くの異なるメトリックを導入しました。たとえば、そのうちの1つであるTimeToImplementを検討してください。これは、メソッドのプログラミングに必要な時間を秒単位で示します。







2690メソッドの実装には1時間以上かかります。

8. RTTI

RTTIは、オブジェクトの動的な型を報告し、実行時に（およびコンパイル時にではなく）型情報を提供するシステムの機能です。 ただし、C ++コミュニティではRTTIの使用について議論の余地があります。 多くのC ++開発者はこのメカニズムを使用しません。



llvm / clang開発チームはどうですか？







dynamic_castキーワードを使用するメソッドはありません。 llvm / clang開発チームは、RTTIエンジンを使用しないことを選択しました。

9.例外

例外サポートは、C ++のもう1つの議論の余地のある機能です。 多くの有名なオープンソースC ++プロジェクトでは使用されていません。



コードのどこかに例外がスローされるかどうか見てみましょう。







RTTIと同様に、例外メカニズムは使用されません。

10.いくつかの統計

10.1。 最も人気のあるタイプ

プロジェクトで最も使用されているタイプを知ることは興味深いです。そのようなタイプは、最適に設計、実装、およびテストされる必要があるためです。 それらの変更は、プロジェクト全体に影響します。



TypesUsingMeメトリックを使用してそれらを見つけます。







人気のある型を見つけるための別の興味深い指標、TypeRankがあります。



TypeRank値は、タイプ依存グラフにGoogle PageRankアルゴリズムを適用することにより計算されます。 平均TypeRankが1に等しくなるように、0.15の中心ホモジティが適用されます。



TypeRankが高い型は、バグがより悲惨になる可能性があるため、より慎重にテストする必要があります。



以下は、TypeRankメトリックに基づくすべての一般的なタイプの結果です。

10.2。 最も一般的な方法

10.3。 他の多くのメソッドを呼び出すメソッド

どのメソッドが他の多くのメソッドを呼び出すかを知ることは興味深いです;これにより、設計上の問題が明らかになります。 場合によっては、読みやすく保守しやすくするためにリファクタリングが必要です。

まとめ

LLVM / Clangは非常に適切に設計および実装されており、他のプロジェクトと同様に、何らかのリファクタリングによって改善できます。 この投稿では、ソースコードで可能な最小限の変更の一部を明らかにしました。 ソースコードを研究し、C ++の知識を向上させることを恐れないでください。