【发布时间】：2010-06-09 19:34:42
【问题描述】：
从 Java 类中计算代码行数的最佳方法是什么，不包括 cmets 和空白行。
【问题讨论】：
-
来自 .java 或 .class 文件？因为 .java 是标准文本文件。
-
.class 文件中没有代码行。
【发布时间】：2010-06-09 19:34:42
【问题描述】：
见JavaNCSS。还要注意 LoC 是一个毫无价值的“指标”。
我现在将通过引用 Dijkstra 来公开appeal to authority：
这种做法普遍存在一种令人安心的错觉，即程序只是与其他任何设备一样的设备，唯一的区别是它们的制造可能需要一种新型的工匠，即。程序员。从那里开始，用“每月产生的代码行数”来衡量“程序员的生产力”只是一小步。这是一个非常昂贵的度量单位，因为它鼓励编写平淡无奇的代码，但今天我对即使从纯粹的商业角度来看它是多么愚蠢的单位也不感兴趣。我今天的观点是，如果我们想计算代码行数，我们不应该将它们视为“产生的行数”，而是“花费的行数”：当前的传统智慧是如此愚蠢，以至于将其计入错误的一边账本。
——EWD，On the cruelty of really teaching computing science
更新：如果您将此作为练习练习，那么您可能应该使用解析器并计算实际语句。
【讨论】：
-
我不同意。如果使用得当，LOC 是一个非常有用的指标。我同意通过 LOC 衡量程序员的生产力是愚蠢的，原因与您所说的相同。但是，使用 LOC 来衡量代码库的增长非常有帮助。如果您的团队在测试期间代码库增长了 50%，该怎么办？这些指标绝对有用……恕我直言。
-
@Hank Gay：您所做的逻辑谬误不是“诉诸权威”，而是“稻草人”，因为 OP 没有表示他想衡量“程序员的生产力”。除此之外，还有 很多 种 LOC 有意义的情况：例如，在重构巨大的意大利面条混乱时，事后看看有多少 *LESS 你拥有的代码行。无论如何，即使说 “我正在开发 5000/10000 行代码库” 并没有多大意义，我怀疑你的 5K/10KLOC 应用程序能否完成隔壁程序员正在工作的 300KLOC就可以了。对于millionLOC等也是如此。
-
即使衡量代码库的增长，它（几乎？）也是毫无希望的过程。知道您的实际逻辑和测试消耗大致相等的 LoC 会告诉您什么？分支覆盖几乎肯定更有用。
-
@NoozNooz42 回复：Strawman -> 我会假设 压倒性 大多数情况下，有人试图获得 LoC 计数归结为“生产力”的一些粗略指标，所以假设大多数情况似乎是合理的。 Re: refactoring -> Reducing LoC through refactoring: 虽然令人满意，但信息量仍然不是很大。打你的代码可能会减少 LoC，但它无助于可维护性。回复：功能数量 -> 如果您开始谈论多个数量级的差异，那么您可能是对的。不过，可能还有更好的指标。
CodeAnalyzer 是处理*.java 文件的好工具。
我们使用了FindBugs，它给出了.class文件中的代码行。 *.java 文件有 99 行，不包括 cmets 和空白行，但 .class 只给出了 59 行。
所以我认为除了简单地删除 cmets 和空行之外，类文件中会发生更多的压缩
【讨论】：
切换到classes目录，输入bash代码：
find . "(" -name "*.java" ")" -print | xargs wc -l
它可以显示所有*.java文件的行数并统计所有文件的总行数。
【讨论】：
-
问题说不包括 cmets 和空行。这个命令
find . "(" -name "*.java" ")" -print | xargs wc -l的结果不排除cmets和空行。