【发布时间】:2013-05-02 10:01:53
【问题描述】:
我的大部分 javascript 代码文件如下所示:
(function() {
var Foo = function() {
...
};
var Bar = function() {
...
};
...
}());
我尝试了许多计算代码圈复杂度的工具,但它们都生成了错误的报告(从我的角度来看),即:它们都将包装函数指向最复杂的函数.
这样做的问题是所有报告都被这个事实严重扭曲:包装函数通常占据复杂度饼图的一半以上,并且所有平均数字都有偏差。
有没有办法获得我的代码的真实复杂性,而不受包装函数的影响?
所有这些工具都做错了吗?将我的代码包装在一个函数中以进行范围界定(我不这么认为),我做错了吗?我使用这些工具做错了吗?
编辑
有人建议在计算复杂度之前删除包装函数,我很乐意这样做,但是有没有可靠的方法可以自动完成?请忽略这个并寻求适当的解决方案。
【问题讨论】:
-
只去掉包装函数?
-
@Griffin 范围呢?那么所有的函数和变量都是全局的。这正是使用包装函数的意义所在。
-
您介意告诉我们您使用了哪些工具,以及他们报告了什么吗?
-
如何告诉我们一个真实的例子,报告的价值,以及为什么你认为它是错误的? (圈复杂度的定义非常仔细;您认为该工具无法正确计算它吗?)这里没有足够的信息来理解实际的抱怨。
-
嗯,也许我在说一些非常愚蠢的事情(永远不要通过这些工具运行我的代码),但关键是所有这些闭包都混淆了它们的内部工作。由于仅为分析而删除所有包装器是疯狂的,您可以改为传递一个可选的“跟踪器”对象并将要公开以供分析的函数/对象附加到此“跟踪器”?它将在全局范围内可用,但会避免污染并绑定代码以某种有序结构进行分析。我的 2 美分 :)
标签: javascript jshint cyclomatic-complexity