【问题标题】:Cyclomatic complexity using jar files使用 jar 文件的圈复杂度
【发布时间】:2010-01-14 09:00:40
【问题描述】:

我正在做一个项目,该项目需要我找出 Apache ant 的圈复杂度(版本 1.1 到 1.6)。我被要求为此目的使用 jar 文件。我使用了几个工具(Xdepend 试用版和 Cyvis)来查看结果。然后我尝试使用 Ant Ver1.6 源代码的结果来验证结果。为了分析源代码,我使用了 Netbeans 插件,还手动找到了一些方法的 CC。

我发现在很多情况下 jar 文件中的 CC 几乎相同,但在某些情况下存在很大差异。我检查了一种这样的方法,我发现它包含很少的 try 和 catch 块。我的问题是:

  1. java 编译器是否执行优化(比如循环展开),这可能主要影响 CC 值?是否建议使用 jar 文件进行此类分析?
  2. try 和 catch 块是否存在一些具体问题,在这种情况下我可以考虑其他方法进行分析?
  3. 有没有更好(更准确)的工具来进行此类分析?

请分享您在此主题上的经验。提前致谢。

干杯

【问题讨论】:

标签: java cyclomatic-complexity


【解决方案1】:

复杂性度量(如圈式)的目的是衡量程序的结构,因为它会影响程序员理解代码库的能力;例如维护它。由于程序员在源代码级别查看代码,因此衡量源代码复杂性才是真正重要的。

如果你通过分析字节码文件得到的测量值与常规的源代码测量值不同,那么它们毫无价值,你应该放弃这个想法。

(对于来自字节码文件的 CC 度量不同,我不会感到惊讶。一方面,编译器可以重新组织代码以使其看起来更简单;例如,通过展开循环。另一方面,编译器可能需要为简单的语言结构生成看起来很复杂的字节码序列,仅仅是因为字节码可以表达的限制。)

【讨论】:

    【解决方案2】:

    这不是您问题的完整答案..

    Java 编译器将像任何其他优秀的编译器一样进行许多优化。其中一些将包括循环不变代码运动、公共子表达式消除、强度减少和变量分配。

    但是Java hotspot 是 Java 字节码执行引擎,它将动态编译字节码以在运行时对其进行优化。

    所以有很多因素会使 src 代码 CC 与字节代码 CC 发生偏差,但这并不意味着改进 CC 不是一项有价值的工作,对 src 代码的 CC 评估对于可维护的干净代码至关重要。

    【讨论】:

      猜你喜欢
      • 2015-05-11
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-10-29
      • 2013-09-03
      • 1970-01-01
      相关资源
      最近更新 更多