7

広く自動化されたソース コード分析およびリエンジニアリング (変換) ツールの開発を容易にする (単純化する) プログラミング言語の一般的な特性/特性は何ですか?

私は主に、静的分析ツールとリファクタリング ツールの開発を容易にするプログラミング言語の機能について考えています (つまり、Java と C++ を比較します。前者はリファクタリングのサポートが優れています)。

言い換えれば、自動化された静的分析とリファクタリングを最初からサポートするように明示的に設計されたプログラミング言語は、どのような特徴を備えていることが望ましいでしょうか?

たとえば、AdaにはASISがあります。

Ada Semantic Interface Specification (ASIS) は、階層化されたオープン アーキテクチャであり、Ada ライブラリ環境へのベンダーに依存しないアクセスを提供します。これにより、Ada プログラムとライブラリの静的分析が可能になります。ASIS (Ada Semantic Interface Specification) は、アプリケーションが Ada コンパイル ユニットの完全な構文および意味構造にアクセスできるようにするライブラリです。このライブラリは通常、Ada プログラムである種の静的分析を実行する必要があるツールで使用されます。

ASIS 情報: ASIS は、ツールが Ada コンパイラまたはその他のソース コード アナライザーによって最適に収集されるデータを抽出するための標準的な方法を提供します。ASIS を使用するツール自体は Ada で記述されており、ASIS をサポートする Ada コンパイラ間で非常に簡単に移植できます。ASIS を使用すると、開発者は高度な移植性を備えた強力なコード分析ツールを作成できます。また、ソース プログラムからセマンティック情報を抽出するアルゴリズムを実装するためのかなりの費用を節約できます。たとえば、ソース コード メトリクスを生成し、コーディング スタイルや制限事項に対するプログラムの適合性をチェックし、相互参照を作成し、検証と検証のためにプログラムをグローバルに分析する ASIS ツールは既に存在します。

ASIS FAQも参照してください。

特に分析/変換目的でソースコードを操作するための、同様に包括的で完全なインターフェイスを提供する他のプログラミング言語を思いつきますか?

実行時に AST または ASG を検査する方法を提供するコア ライブラリ関数など、低レベルのフックを提供する特定の実装手法について考えています。

4

7 に答える 7

8

最大のものは静的型付けでなければなりません。これにより、ツールはコードが何を行っているかについてより多くの洞察を得ることができます。それがなければ、リファクタリングは何倍も難しくなります。

于 2009-06-10T20:23:04.190 に答える
2

これはまだほとんど解明されていない問題だと思います。「ツールのための言語設計」という概念は、最近になって主流の端っこに入っただけのようですが、この分野の研究は 20 年以上前のものだと思います。他の2つの回答、つまり「静的型付け」と「自己相似性」は、リファクタリングのサポートを容易にする言語の有用な特性であることに同意します。

于 2009-06-14T16:42:13.757 に答える
2

特定のプログラミング言語によって分析が容易になることは事実です。分析しやすい言語が必要な場合は、純粋に機能的な言語を選択してください。

しかし、純粋な関数型言語で実際にプログラムを作成する人は誰もいません。(Haskell 関係者はこれを見て飛び跳ねますが、真剣に言えば、Haskell はごくまれにしか使用されません)。

プログラミング言語を分析可能にするのは、分析をサポートするように設計されたインフラストラクチャです。上記の Ada の ASIS はその好例です。ASIS が Ada 用に作成された、または Ada で作成されたという事実を混同しないでください。重要なのは、真剣に Ada を分析したいと考え、Ada 分析機構を構築するための労力を投資したということです。

適切な治療法は、一般的な分析インフラストラクチャを構築し、それを多くの言語で償却することだと私は信じています。その一方で、一般的な変換インフラストラクチャも構築する必要があります。分析を行ったら、それを使用して変化をもたらしたいからです。（医師の診察は診断で終わるのではなく、治療で終わります）。そして、私はそれに自分のキャリアを賭けてきました。

その結果、分析、リファクタリング、リエンジニアリングなどに理想的なエンジンであるDMS ソフトウェア エンジニアリング ツールキットが完成しました。

これには、一般的な解析、ツリー構築、prettyprinting、ツリー操作、ソースからソースへの書き換え、属性文法評価、制御およびデータ フロー分析があります。Java、C#、COBOL、PHP、さらには Verilog や VHDL (他の多くの言語も同様ですが、そのレベルではありません) など、広く使用されている C および C++ の多くの方言に対する製品品質のフロント エンドを備えています。

そのユーティリティの感覚をつかむために、B-2 爆撃機の JOVIAL コードを C に変換するために使用されました...ソース コードを見たことはありません。http://www.semdesigns.com/Products/Services/NorthropGrummanB2.htmlを参照してください。

さて、分析インフラストラクチャがあると仮定すると、どの言語機能が役立つでしょうか?

静的型は、変数が取り得る値のセットを制限することで役立ちますが、「X は整数です」など、制限された単一引数の述語を追加することによってのみ有効です。コード内のアサーションは、状態変数間の関係を確立する複数の引数を持つ述語をキャプチャするため、コード内のアサーションがより役立つと思います。これ は、コードを検査してもしばしば見つけることができません (たとえば、問題またはドメイン固有の情報、たとえば、「X > Y+3".) 分析インフラストラクチャ (および率直に言って、コードを読み取るプログラマー) は、理想的には、このような追加の事実を利用して、より効果的な分析を提供できます。

このようなアサーションは、通常、「assert」、「pre(condition」、「post(condition」) などの特別なキーワードでコード化されます。これらのキーワードは、定理を証明する文献から十分な理由が得られたものです。

しかし、あなたの言語にアサーションがなくても、とにかくエンコードするのは簡単です: アサーションの否定を含む条件で if ステートメントを書くだけで、ボディは不可能を示す慣用句を呼び出すか、言語のセマンティクスに違反します (たとえば、"if (x>0) fail();" のように、明らかに null ポインターを deref します)。

したがって、本当に必要なのは言語でのアサーションではなく、アサーションを喜んで作成するプログラマーです。残念ながら、それは悲しいことに欠けているようです。

于 2009-06-14T04:57:40.457 に答える
1

言語/型システムに組み込まれたリフレクション。これにより、静的分析とリファクタリングの負担が大幅に軽減されます。

これが、Java および .NET ツールが非常に一般的で優れている理由の一部です。これにより、ソース コードの依存関係を迅速かつ確実に理解するという点で、はるかに優れた機能がツールに提供され、ソース コードの静的分析に役立ちます。

さらに、コンパイルされたコードの分析も行うことができます。

于 2009-06-10T18:50:25.407 に答える
1

「コードはデータである」パラダイムを共有する言語があります。たとえば、コードのすべての行は、この言語に関しては単なるデータです。これにより、リファクタリングが基本的なデータ操作と同じくらい基本的なアクションになります。そして、この言語の名前は Lisp です。;)

真剣に言えば、「プログラミングのための言語」と「機械のための言語」は、2 つの異なる要件です。そして、分析に最適な言語は、プログラマーにとって悪夢になる可能性があります。さらに、何らかの分析用に設計された言語は、プログラミング言語ではない可能性があります。(先週、ポインター分析用の言語に出会いましたが、テキスト表現はなく、実行可能なステートメントは 2 つしかありません)

繰り返しますが、最初にタスクを定義してから解決する必要があります。たとえば、タスクが「安全なプログラムを書きたい、たとえば、整数オペランドと文字オペランドを決して混在させないようにしたい」場合、静的型を持つ言語が必要です。わかりました、「実行時に外部ライブラリで何ができるかを知る必要があります」 - リフレクションはあなたの選択です。「交換、変換、および分析のための汎用プログラミング言語が必要です」 - ほとんどの場合、これはあなたが本当に望んでいるものではありません。

于 2009-06-14T18:03:28.303 に答える
0

リファクタリングの場合: 自己相似性

侵入的な変更や奇妙な再解釈なしにコードの移植を受け入れる能力。例:

  • 参照パラメーターを使用して変数への変更アクセスを与えることにより、C++ のスニペットを新しいプロシージャーに抽出します。
  • Python、Javascript、および Lua のメソッドは、実際には「self」パラメーターを持つ単なる関数です。*
  • 任意の数の言語で、構造体を作成/設定する関数を (多かれ少なかれ簡単に) コンストラクターに変換できます。

反例...

  • Ruby (モジュール、クラス)、メソッド lambda ブロック、raw ブロック: セマンティクスの違いは控えめに言っても当惑します。（これは、私が確かに言う資格があると感じるすべてです。）

(私の考えでは) 自動マングリングの非常に異なるケースについては、あまり確信が持てませんが、関数型プログラミング言語によって提供される副作用からの自由は本当にそれです。（わかりました。では、他の言語で同じことをどのように提供できるでしょうか?)

*Pythonはほとんどそのようなものです。（問題が何であるかを忘れました。おそらく、メソッドがクラスで定義されているか、ランタイムに移植されている場合に何か関係があります。）

于 2009-06-14T13:56:49.160 に答える
0

IMO の最も重要な特性は、言語が完全に指定され、決定論的であることです。たとえば、C では、次のコードの動作は言語仕様によって定義されていません。

x++ = x++ + ++x;

コードの動作が未定義であるにもかかわらず、コンパイルして何かを実行する場合、その何かを保持する方法で自動的に変更 (つまり、リファクタリング) する安全な方法はありません。

次の重要なプロパティは、スコープ外の変数 (フィールド) へのアクセスを許可しないことです。ポインターを使用すると、たとえば C では、アドレスを「推測」するだけで任意の変数の値にアクセスできます。そのような言語では、特定の変数の値がコードのどこで読み取られたり、変更されたりしたかがわからない場合があります。繰り返しますが、そのようなことを行う可能性のあるプログラムを自動的にリファクタリングする安全な方法はありません。

于 2009-06-15T09:30:28.180 に答える