checkstyle - 实现 Java Checkstyle 检查的准则是什么？

Question

我是 CheckStyle 等 Java 静态代码分析工具的新手。我下载了 Checkstyle 包并看到了 2 组检查:

• checkstyle_checks.xml
• sun_checks.xml。

我比较了这些和 geosoft_checks.xml 所有 available in checkstyle 的主列表...本质上是一个 4 表的完整外部联接，以查看 3 个来源中的大部分都包含了哪些检查。

检查 |来源
----------|------------------------------------ ------------------
134.......| All available
75…………| checkstyle_checks.xml (加上指向 suppressions.xml 的 SuppressionFilter)
63…………| sun_checks.xml
73…………| geosoft_chekcs.xml (在删除在 checkstyle 5.7 中不起作用的 4 之后)

• 双重检查锁定
• PackageHtml
• 制表符
• GenericIllegalRegexp

我只对 sun_checks 和 geosoft_checks 进行了分析，以确定我可以根据代码库中的实际发现安全地删除哪些(当然，有人可能会出现并违反其中一个未包含的许多检查)

是否有最近的指导方针来说明哪些检查包括哪些不会不必要地让开发团队感到沮丧？人们是否使用已回馈给开源社区的有用检查来扩展 checkstyle？

Answer 1

这是一个很好的问题，一个比简单的 SO 帖子更值得回答的问题。让我再试试。

首先，没有公认的通用指南可以帮助您。任何带着这样的指导方针来找你的人实际上只是在推销他自己的东西。所以，我坚信没有什么是你可以简单地采取、激活和完成的。这有点令人难过，但我们就是这样。

sun_checks 大多是历史性的，并且侧重于格式和命名。如果您别无选择，它们可能仍然是最好的开始。 checkstyle_checks 是 Checkstyle 团队用来检查他们自己的代码的工具。我不知道 geosoft_checks，它似乎是一种有据可查的本地指南形式。还有Google Java Style , 这已经很流行了，但是 afaik 还没有相应的 Checkstyle 规则集。

Checkstyle 是一种工具，其功能远不止检查 Java 代码的样式。您已经表明可用检查的数量几乎是规则集使用的检查数量的两倍。我自己的规则集使用 99 项检查，但它是根据我们正在构建的解决方案高度定制的。

就目前情况而言，我相信如果您认真地进行静态代码分析，总有一天您将不得不查看所有可用检查的列表并将您自己的规则集放在一起。随着项目的进行，您将添加它，以涵盖越来越多的案例，在这些案例中，您已经确定正在构建的解决方案中可能存在错误。微调和添加到 Checkstyle 配置文件将是一项持续的任务(例如，每周一小时)。

如果您想避免“不必要地挫败开发团队”，最重要的方面是您的规则要清晰、有据可查且保持一致。此外，将 Checkstyle 与您的夜间构建和/或版本控制系统集成。

最突出的 Checkstyle 扩展是 SevNTU Checkstyle和 Checkstyle Addons . SevNTU Checkstyle 的带头人也是今天 Checkstyle 的主要提交者，所以也许在未来的某个时候两者会合并。