有没有办法让我以某种方式解析我的 java 代码文件并查找 java 文档注释？我想确保我已经为该类和该类的每个方法(或实际上的所有内容)编写了 javadoc。这可能吗？
最佳答案
严重的不回答:不要不要这样做。随后将给出各自的解释；但我的所有意见都源于围绕此类主题的大量经验。
重点是:迟早(更快!)你会遇到你真的很想将更改放入 git 的情况。知道您需要 javadoc 才能实现这一点，您将开始放置虚拟内容，例如:
/** just to make the commit hook happy; @TODO: replace with real content */
我向你保证:迟早你会发现你的代码库中大量这样的 @TODOS 已经腐烂了几天、几周、几个月。因为最终，向支付你工资的客户提供新功能比修复你在某个地方得到的 15 个 @TODO 更重要。我有说15吗？啊，那是上周的事了。现在我们有 25...( LeBlanc's law 稍后等于永远启动!保证)
换句话说:如果您希望在所有地方都有javadoc，但您的纪律今天还不够“好”，无法在没有这种强制执行的情况下实现这一目标;那么这将导致低质量的 javadoc。
除此之外:在专注于“干净代码”实践几年之后，我今天认为:单独使用 javadoc 并不是的答案。虽然我在一家大型企业工作，团队遍布全局。
恰恰相反。当人们被训练编写“可读”代码时，通常他们实际上不需要任何(或只是一小部分)javadoc 来实现这一目标。因为这样他们的设计和命名技巧就达到了代码变得易于阅读而无需太多 javadoc 的水平。
如果人们没有接受过有关这项技能的培训，他们往往会创建无用的 javadoc。我无法告诉你我有多少次告诉人们禁用 Eclipse 模板，该模板在生成新类时会创建绝对无用的 @author 标记。你猜怎么着:仍然有无数次 Eclipse 生成的 javadoc ...它们在生成后从未被任何开发人员接触过。
长话短说:创建有用 javadoc 需要大量的纪律和技能。如果您已经缺乏纪律，那么强制执行“必须有一些 javadoc”规则将不会提高代码的质量!
最后:我并不是说人们不应该彻底研究这些事情。但我宁愿建议
- 定义如何编写 javadoc 的通用准则；哪些信息是强制性的；以及什么样的元素需要javadoc
- 在此基础上，找到自动检查的方法
- 然后定期收集此类信息(例如在夜间构建期间)并密切关注此类统计数据
关于java - 如何创建一个 git hook 来强制我编写 javadoc 注释？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42009632/