此类工具基本上必须至少为该语言的一个子集实现编译器前端。最简单的起点通常是调整现有的编译器前端，因此您绝对应该从查看客户的编译器开始。如果幸运的话，它将在前端和后端之间实现清晰的分离，并且能够按原样使用它并使用 AST 或前端生成的任何 IR 来进行额外的分析。
Such tools basically have to implement a compiler front-end for at least a subset of the language. The easiest starting point is often to adapt an existing compiler front-end, so you should definitely start by looking at your customer's compiler. If you are lucky it will have a clean separation between the front-end and back-end and will be able to use it as-is and use the AST or whatever IR the front-end produces to do your additional analysis.
You don't want to write all this stuff from scratch.
See the DMS Software Reengineeering Toolkit. This has generalized compiler machinery for parsing, building ASTs, constructing symbol tables, constructing/traversing control flow and data flow graphs and call trees.
DMS can be obtained with a full Java front end that builds ASTs, symbol tables and the flow analyses above. DMS handles language dialects with aplomb, so it should be as straightforward as practical to modify this front end to match your customer's Java-variant language and yet acquire all this analysis machinery.
Then by using the PMD rule designer I can define rules from the resulting AST.
The thing I like about PMD is that its a broadly recognised code analysis tool in the Java space so has lots of third party support. E.g Eclipse plugin, Hudson CI plugin etc etc
发布评论
评论（4）
此类工具基本上必须至少为该语言的一个子集实现编译器前端。最简单的起点通常是调整现有的编译器前端，因此您绝对应该从查看客户的编译器开始。如果幸运的话，它将在前端和后端之间实现清晰的分离，并且能够按原样使用它并使用 AST 或前端生成的任何 IR 来进行额外的分析。
Such tools basically have to implement a compiler front-end for at least a subset of the language. The easiest starting point is often to adapt an existing compiler front-end, so you should definitely start by looking at your customer's compiler. If you are lucky it will have a clean separation between the front-end and back-end and will be able to use it as-is and use the AST or whatever IR the front-end produces to do your additional analysis.
您不想从头开始编写所有这些内容。
请参阅 DMS 软件再造工具包。这已经通用化了用于解析、构建 AST、构建符号表、构建/遍历控制流和数据流图以及调用树的编译器机制。
DMS 可以通过完整的 Java 前端来获得，该前端构建 AST、符号表和上述流分析。 DMS 能够沉着地处理语言方言，因此修改此前端以匹配客户的 Java 变体语言并获取所有这些分析机制应该尽可能简单实用。
You don't want to write all this stuff from scratch.
See the DMS Software Reengineeering Toolkit. This has generalized compiler machinery for parsing, building ASTs, constructing symbol tables, constructing/traversing control flow and data flow graphs and call trees.
DMS can be obtained with a full Java front end that builds ASTs, symbol tables and the flow analyses above. DMS handles language dialects with aplomb, so it should be as straightforward as practical to modify this front end to match your customer's Java-variant language and yet acquire all this analysis machinery.
那么 PMD 呢？我已经使用 PMD 多年，但之前从未真正深入了解其内部工作原理。
PMD 可以通过编写自定义语言解析器来扩展，这是通过在类路径上的 JAR 中提供以下内容的实现来完成的。
net.sourceforge.pmd.cpd.Language
net.sourceforge.pmd.cpd.Tokenizer
http://pmd.sourceforge.net/cpd -parser-howto.html
然后通过使用 PMD 规则设计器 我可以定义来自生成的 AST 的规则。
我喜欢 PMD 的一点是，它是 Java 领域广泛认可的代码分析工具，因此拥有大量第三方支持。例如 Eclipse 插件、Hudson CI 插件等
What about PMD? Ive used PMD for years but never really drilled down into its inner workings before.
PMD can be extended by writing a custom language parser, which is done by providing implementations of the following within a JAR on the class path.
net.sourceforge.pmd.cpd.Language
net.sourceforge.pmd.cpd.Tokenizer
http://pmd.sourceforge.net/cpd-parser-howto.html
Then by using the PMD rule designer I can define rules from the resulting AST.
The thing I like about PMD is that its a broadly recognised code analysis tool in the Java space so has lots of third party support. E.g Eclipse plugin, Hudson CI plugin etc etc
看看 FindBugs
Take a look at FindBugs