我是像CheckStyle这样的Java静态代码分析工具的新手。我下载了Checkstyle包并看到了两组检查：
我将这些和 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（删除 4 后无法在checkstyle 5.7 中工作）
我只对sun_checks和geosoft_checks进行了分析，以确定哪些可以根据代码库中的实际结果安全删除（当然有人可以出现并违反其中任何一项检查中未包含的检查）
是否有最新的指导方针，包括哪些检查不会对开发团队造成不必要的挫败？人们是否通过有用的检查扩展了checkstyle，这些检查已经回馈给开源社区？
答案 0 :(得分：2)
这是一个很好的问题，而且需要比简单的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的主要提交者，所以也许两者将在未来合并一段时间。