コードビューティファイアのパーサーの選択
私はコードビューティファイアを作成する計画段階にあります（ AStyle または ncrustify に似ています）-もともと私はそれらのプロジェクトの1つに貢献するつもりでしたが、ソースから、私にはさまざまな設計目標があり、それらのソースは部外者が簡単に貢献するのが難しい方法で書かれているという結論に至りました。たとえば、AStyleは、ある種のASTを構築する代わりに、isInComment、foundClassHeader、isLineReadyなどの100を超える状態変数を使用します。
スキャナーとパーサージェネレーター（flexやbisonなど）を使用するか、独自の解析システムを作成するかを決定しています。どちらがより良いアプローチでしょうか？私は大学でコンパイラのクラスを経験したことがあるので、スキャンと構文解析の理論についてある程度の経験があります。以下は、それぞれについて私が考えた利点です。
ジェネレータ
- 間違いなく開発が簡単/迅速
- カスタムパーサーでの最初のスタブよりもおそらく最適化されていますが、カスタムパーサーでは改善の余地があります。
カスタムパーサー
- 間違いなくデバッグが簡単
- プログラマーは、過去の質問でカスタムレクサーとパーサーを好むようです- "きちんとしたレクサーを必要とする人は、Lexを使用しません"
- 依存関係が少ない
- 「ファジーな」解析を可能にする可能性があります-私は美化機能を開発しているだけなので、パーサーはコンパイラの場合と同じくらい厳密または詳細である必要はありません
- 並列化-flexとbison（または私が見たもの）はグローバル状態を使用します。複数のファイルを一度に（別々のスレッドで）解析したい場合は、カスタムソリューションを区分化する方が簡単です
フレックス/バイソンか何もないかの選択ではありません。そこにいくつかのオプションがあります。私は最近のプロジェクトに antlr を使用しましたが、作業するのは非常にいいことです。あなたが考慮しなかったかもしれないいくつかの事柄：
- レクサーはそれほど難しいことではありませんが、パーサーには、あなたがヒットするまで気付かないかなりの数の落とし穴があります。広く使用されているツールは、まだ存在さえ知らない多くの問題をすでに解決しています。
- パーサーはコンパイラと同じくらい厳密でなければなりません。違いは、場所によってはより単純な文法を使用できることですが、他の場所ではより複雑な文法を使用する必要があるため、おそらく相殺されます。たとえば、コードの美化者は、通常のコンパイラが「空白」にまとめるだけの意図的な改行を保持したいことがよくあります。言語にプリプロセッサがある場合、美化機能はそれを文法に組み込む必要がありますが、コンパイラのパーサーはそうしません。
- 文法のデバッグは非常に困難です。 antlrのようなツールは、有用なエラーメッセージを生成するためにかなりの労力を費やしています。カスタムパーサーを使用する場合でも、既存のパーサージェネレーターを使用して文法をデバッグすると便利な場合があります。