Clojure程序的特定软件度量

我们正在考虑编写一个静态分析器来收集Clojure代码的软件度量。当然，它会处理一些明显的东西，比如文件数量、函数、每个函数的参数等等。我想知道是否有任何特定于Clojure代码的指标。有什么想法吗？

平均而言-我认为软件度量是一个可疑的想法-它们通常会让你从真正重要的问题上分心，那就是“我们向客户提供了多少价值？”

话虽如此，我认识到它们在某些情况下可能是一种必要的邪恶，偶尔也会给您一些关于代码库的有用见解

这里有一些可能是Clojure特有的

• 顶级定义的数量（可能表示为与符号总数的比率？）
• Java耦合：与Java互操作相关的符号的百分比（new、ClassName.、.someMethod等）-理想情况下，将耦合限制在负责Java互操作的特定模块中，即除管理互操作的库外，其他所有模块的耦合率都应非常低%
• 函数defns的平均最大嵌套级别（我猜5个稍好，10个以上坏？？）
• 宏密度：需要宏扩展的窗体的百分比
• %具有docstring的函数类型
• %使用类型提示定义的符号或函数参数的类型
• 匿名函数的平均大小（这些函数应该很小！）
• %使用clojure.core中函数的数量（给出了一些关于“词汇范围”和代码复杂性的想法）
• （感谢nickik！）创建的ref类型的数量（动态变量、atom、ref和代理）-如果您想仔细控制可变状态，这是必不可少的

---

p、 如果你能做到这一点，那么看到一些不同的开源clojure项目之间的结果差异将是非常有趣的

我理解这种反度量的情绪。我认为衡量标准只对放大问题区域有用。很好的回答顺便说一句。计数参考类型真的是不可能的。计算ref/atom/agent和动态变量（见1.3）。@nickik-完全同意ref类型非常重要。虽然很难弄清楚在静态分析仪中使用什么度量标准？我预见到的问题是，这些通常是动态分配的，因此仅计算ref/atom/agent符号并不一定有帮助，例如。。。。。不管怎样，我已经添加到列表中，我认为静态地做它和跟踪实际对象的数量一样好。如果你只在一个地方创建原子，其复杂性可能会受到同样的限制：即使该函数被调用一千次，它也不会变得更复杂。