8

就我而言，这样做有两个原因：

  • 有时人们会错误地导入在 macbooks JDK 中存在但在 Linux 中不存在的类。这会导致在基于 Linux 的机器上的 ci 服务器上构建失败。我不经常发生，但是当它发生时，我想应该有一些更聪明的方法来更早地发现它。
  • 未使用的导入在 IDE/代码分析中触发警告。有时有人需要花时间清理这些东西。即使只是在 IDE 中单击鼠标右键，您仍然需要提交更改并确保构建时一切正常。

我很好奇是否有任何方法可以以编程方式找到未使用的导入（让我们从单元测试中说）并在本地失败（如果有的话）。

也许由于未使用的导入而导致构建失败听起来很苛刻，但如果它为整个团队节省了时间，那么这样做是有道理的（也很想听听对此的意见）。

更新：

我遵循了 yegor256 的建议，并将 Checkstyle 任务与最初的一小部分Sun 代码约定（未使用的导入就是其中之一）合并，并在发现违规时使其中断构建。

经过一周的试用，我们的代码库中未使用的导入为零，令人惊讶的是，对此规则的投诉为零（顺便说一下，Checkstyle 非常快：分析 ~100KLoc 只需不到一秒的时间）。

至于使用 IDE 进行此类分析：是的，这是一个不错的选择，但是将这种检查作为自动构建的一部分运行会更好。

4

6 回答 6

9

您正在尝试做的事情称为静态代码分析。Checkstyle可以为您提供帮助。如果您使用 Maven，此插件将为您完成自动化：http ://maven.apache.org/plugins/maven-checkstyle-plugin/

你也可以看看qulice.com（我是它的开发者之一），它集成了一些静态分析工具并预先配置了它们（包括 Checkstyle、PMD、FindBugs）。

于 2012-09-17T05:29:03.990 回答
4

如果您使用的是 eclipse IDE 或 IntelliJ IDEA，您可以将它们配置为

1a。在保存或提交之前组织导入/删除未使用的导入（请参阅清理首选项）

1b。将“未使用的导入”警告切换为错误（请参阅错误设置）

2a. 配置一个不包含 com.* 东西的 jre

2b。将来自 jre 的专有 api 使用警告配置为错误

不过，您可能仍想在构建服务器上进行检查。在这种情况下，仍然需要配置 CheckStyle 等更复杂的东西。

于 2012-09-17T09:32:12.047 回答
1

我很好奇是否有任何方法可以以编程方式找到未使用的导入（让我们从单元测试中说）并在本地构建失败（如果有的话）。

我使用 IntelliJ 来组织导入，这将删除所有未使用的导入。您可以使用代码库顶部的一个热键来更正所有导入。（它还有超过 700 种其他类型的静态检查和修复）

也许由于未使用的导入而导致构建失败听起来很苛刻，但如果它为整个团队节省了时间，那么这样做是有道理的（也很想听听对此的意见）。

我让 IntelliJ 签入格式化并组织导入的代码，因此问题从一开始就不会出现。;)

于 2012-09-17T07:45:11.820 回答
1

我看到很多评论与使用这个 IDE 或那个 IDE 的方式相同。但我所有的朋友都试图理解其中的区别。以编程方式做某事是不同的，使用 IDE 是不同的。

如果我希望一个过程是程序化的，那么 IDE 的建议是没有用的。有人可能会问这个问题，因为他正在构建完整的流程，而这一步是其中的一部分。在 CI 工作的不同机器和操作系统上，打开 IDE 如何帮助他？

我也在类似的线路上构建了一个工具。我在某种程度上实现了它，但它以编程方式打开 IDE 并自动关闭它并修复源代码。但是在 Linux 中打开同样的东西对我来说可能是个问题。

在回答之前了解某人的观点确实非常重要。

于 2016-10-13T12:15:44.187 回答
0

在计算机科学中，这种无需执行即可分析代码的过程的名称称为static code analysis.

尝试使用 IDE，我正在使用 Eclipse，它用黄色下划线标记所有未使用的导入和未使用的变量或方法....

于 2012-09-17T06:19:30.537 回答
0

这些不是无关的问题吗？如果您导入仅存在于本地 JDK 中的类，则会使用这些导入（只是不满意）。对于任何一个问题，我建议在 IDE 中解决它，以便在编写代码时检测到问题，而不是在签入之前（检测越早，修复越容易......）。

在 Eclipse 中，您可以通过访问规则防止不满意的导入，并在保存源文件时通过启用适当的保存操作自动修复导入。如果您将这些设置检查到版本控制中，您可以轻松地与团队共享它们。

于 2012-09-17T06:25:29.983 回答