用于强制圈复杂度和 LCOM 约束的注释
在工作中,我们使用多种工具来捕获多种指标(主要是圈复杂度和 LCOM)。我们使用它们来获取警告标志并指导先发制人的重构工作。这对于提高代码质量非常有益。
但是,该过程与构建过程无关。它是单独进行的。此外,我正在寻找可以成为源代码固有的东西(而不是在其上运行的外部进程。)
是否有人知道可以从编译器,如果代码不符合阈值圈/LCOM 指标,这将使构建失败?
我想我可以从 maven/ant 运行 ckjm、checkstyle 和 pmd,但是一些工作在源代码上,其他工作在字节码上。如果有一个可以在编译开始之前处理源代码的综合工具,那就太好了。
另一件事是,如果有一组注释可以驱动它(以允许在极端情况下不可避免地需要的自定义),那就太好了。
@LCOM3(Threshold=1.5)
public class SomeDumbPojo {... buch of gets/sets...}
// by default would be measured against a strict LCOM3
public class ActualBizClass
{
@CYCLOMATIC_COMPLEXITY(Threshold=15)
public void someFatIrreducibleMethod(){...}
}
然后,当我们运行该工具时,默认情况下应用严格(并且可配置) )度量阈值,除了那些用(希望有记录且合法的)更宽松的阈值注释的工件。对于一些不能/不应该减少的方法,放宽圈复杂度是有意义的。对于没有行为的普通 POJO,LCOM 需要放松......等等。
尽管我可能进行查找和谷歌搜索,但我找不到任何东西(希望是开源的)。但我不妨在这里问一下,以防万一有人知道此类事情。
谢谢。
At work we are using several tools to capture several metrics (mostly cyclomatic complexity and LCOM). We use those to get warning flags and to guide pre-emptive refactoring efforts. It's been very beneficial in increasing code quality.
However, the process is not tied to the build process. It is conducted separately. Moreover, I'm looking for something that can be made intrinsic to the source code (as opposed to an external process ran on it.)
Is anyone aware of a group of annotations and configurable annotation processor(s) that can be run from the compiler, and which will make the build fail if code doesn't comply with threshold cyclomatic/LCOM metrics?
I guess I could run ckjm, checkstyle and pmd from maven/ant, BUT some work on source code, and others work on bytecode. It would be nice to have one consolidated tool that works on the source code before compilation begins.
The other thing is that it'd be nice if there are sets of annotations that could drive this (to allow customization that will be inevitably be needed for corner cases.)
@LCOM3(Threshold=1.5)
public class SomeDumbPojo {... buch of gets/sets...}
// by default would be measured against a strict LCOM3
public class ActualBizClass
{
@CYCLOMATIC_COMPLEXITY(Threshold=15)
public void someFatIrreducibleMethod(){...}
}
Then, when we run the tool, by default applies strict (and configurable) metric threshold except on those artifacts that are annotated with (hopefully documented and legitimate) more relaxed thresholds. For some methods that cannot/should not be reduced, a relaxed cyclomatic complexity makes sense. For plain POJOs w/o behavior, LCOMs need to be relaxed... and so forth and so forth.
Looking and googling as I might, I have not been able to find anything (hopefully open source). But I might as well ask here just in case anyone is aware of anything of the sort.
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我不太确定这意味着什么,因为必须将代码编译成某种东西才能使静态分析发挥作用。所有这些工具都需要能够将代码编译为字节码或某种语法树。
我建议保持简单:配置 PMD,如果环复杂度或其他指标的任何警告超过给定阈值,则构建失败。不要用允许的复杂性来注释该方法(您如何得出可接受的值?如何防止有人意外地将复杂性从 12 增加到 15 以增加注释),而是对其进行注释以完全抑制警告,
然后定期您可以在代码库中搜索包含您可能想要删除和重构的抑制警告的方法。
或者,如果您想提供某种可追溯性,PMD 支持以某种语法在代码中留下注释,以标记谁审核了警告以及何时审核。
I'm not quite sure what this means as the code has to be compiled into something in order for static analysis to work. All of these tools need to be able to compile your code either into bytecode or some sort of syntax tree.
I would suggest keeping it simple: configure PMD to fail the build if any warnings for Cyclomatic Complexity or other metrics cross a given threshold. Instead of annotating the method with the allowable complexity (how would you derive an accepted value? what's to prevent someone who accidentily increased the complexity from 12 to 15 to just bumping up the annotation), annotate it to suppress the warning completely
And then periodically you can search your codebase for methods with suppressed warnings that you might want to remove and refactor.
Alternatively, PMD has support for leaving comments in the code in a certain syntax to mark who audited the warning and when, if you'd like to provide some sort of traceability.
SD Java Metrics 工具计算最基本的指标(不是 LCOM,而是肯定的圈复杂度) ),并从命令行运行。
它生成一个 XML 输出文件,其中包含有关方法的详细度量以及上面的层次结构(类、包、子系统)的汇总摘要。使用 XLST(或 awk 或 perl 或...)可以很容易地提取完整摘要或单个方法所需的指标,并根据您的阈值进行检查。
The SD Java Metrics tool computes most basic metrics (not LCOM but certainly Cyclomatic complexity), and runs from the command line.
It produces an XML output file, with detailed metrics on methods and rollup summaries for hierarchies above that (class, package, subsystem). Using XLST (or awk or perl or...) It'd be very easy to extract the metric you want for the full summary or for an individual method, and check against your threshold.