我最近在我的C ++代码库上运行CCCC并收到了不少红色标记（链接中可以看到示例output of CCCC on a code base (not my code base)）。我知道红色标记可能是由于基本的复杂性或偶然的复杂性，但CCCC并不区分这两者。我最关心的是我的代码库中名为“Henry and Kafura's information flow complexity”的模块化度量值，它有很多红色标记。是否有任何工作描述任何工作流程建议或减少红色标记数量的处方？
答案 0 :(得分：5)
考虑到所涉及的课程，这些红色标记是可以预期的。
string和ostream都有很高的扇入，但没有扇出。这意味着您将数据放入字符串或将数据发送到ostreams。使用string的16个模块并非不合理，使用ostream的16个模块也不合理。
您的CDistribution模块具有适度的扇入和扇出，这意味着多个模块会向其发送数据，而多个模块会从中接收数据。据推测这就是它被称为CDistributor的原因，因为它将模块中的某些东西分发到其他模块，而不会直接了解彼此。据推测这是设计上的。
您可以通过删除架构并让模块直接相互调用来删除CDistribution的红色标记！当然，这不是一个严肃的建议。你的架构似乎是合理的，只有CDistribution上有一个红色标记表示你已经将所有这些依赖项压缩到一个明确定义的位置，这是一件好事。
至于删除string和ostream的红色标记，您必须减少对这些类的依赖关系，但它们是基础类。想象一下全局整数+运算符的“扇入”有多大！有些事情只是被广泛使用，这就是你所看到的。
答案 1 :(得分：0)
通过改进代码来改进指标。这将是最有用和最普遍适用的方法，IMO。
您要做的最后一件事是通过某种过滤来屏蔽指标。没有什么比谎言的统计更浪费时间了。
明智地使用它们，但不要使它成为你的宗教。住一些红色标记
编辑，如果你真的想打击他们的红旗＆＃39;，这是我能想到的最通用的广告：
当然，这不能治愈孤立的连接模块以及还有什么可能是错误的，但它确实是一个良好的开端，可以传播＆＃39;稀释＆＃39;信息复杂性一般