Delphi 如果我清理我的uses条款，如果移除的单元仍在其他单元中使用，会有区别吗？

就我个人而言，如果我的

uses

子句尽可能小，我会喜欢它，但在许多应用程序中，像

Forms

或

VirtualTrees

这样真正大的单元至少在另一个单元中需要

---

所以：如果我清理我的

uses

子句，即使最终没有从项目中删除任何单元，这会有区别吗？如果是：以什么方式？还有：清洁

uses

条款是应该尽快完成的，还是可以等到我偶然发现一个未使用的单元

如果在项目的其他地方使用它，除了生成更清晰、更易于阅读的代码外，不会有太大的区别。不过，它可能会影响一些小事情

编译顺序：编译器根据哪些单元使用哪些单元来决定编译单元的顺序。如果从早期单元的uses子句中删除单元，则可能会导致在编译周期的后期编译所使用的单元。这听起来可能不多，但请记住，初始化部分的运行顺序与编译单元的顺序相同。不过，这对你的项目不会有太大影响

---

CodeInsight：当您打开“代码完成”下拉列表时，它将根据当前可用的所有单元提供选择。你可以减少它需要过滤的选择的数量，从而减少它需要花费的时间--通过减少使用的单位数量。（不，我不苦。你为什么要问？

通常不。如果一个装置在项目中的任何地方使用过一次，不管它使用了多少次。相反，如果一个单元在某个地方至少使用过一次，那么从多个地方移除它并不重要。编译后的程序将表现相同，并且大小大致相同

唯一的区别在于单元初始化和最终确定部分的顺序。单元使用顺序会影响这些部分的执行顺序，尽管从未记录过确切的效果（因此尽量不要依赖于初始化顺序）

---

但是我仍然鼓励你清理你的单位列表，因为同样的原因，你被鼓励清理你的变量列表和参数列表。当你扔掉你不需要的东西时，阅读你保存的代码就变得更容易了，因为你可以有理由相信你正在阅读的东西能够准确地描述代码的功能。如果您的代码提到了一堆单元，但从未真正使用过它们，那么下次您或其他人查看代码时，会有一个很好的变化，您将花一些时间尝试找出代码在哪里使用这些单元的功能。（你会对自己说，“嗯，这段代码包括

图形

，但我看不出它在哪里画东西。我最好再看一看，因为我认为这段代码没有那样的责任。嘿，同事-你能抽出一天的时间告诉我这个单元在哪里画东西吗？”）

使用免费的Pascal分析器找出代码中未使用的单位。

是的，有一个技巧经常被忽视，可能会从背后咬到你：
如果存在一些初始化/终结代码，则即使在您的单元中没有其他调用的代码时，也会始终执行该（并且单元始终包括在内，而您认为不会包括在内）。因此，删除项目中不需要的单元可以带来显著的不同

另一件值得注意的事情是，当两个不同的单元中有同音词时，单元的顺序决定了编译器选择的标识符，并且您在调用它们时不必使用单元名称前缀（作为最佳实践，您应该始终这样做）

除此之外，正如Mason和Rob所指出的，单元顺序会影响它们的编译顺序以及初始化/终结的顺序

---

至于代码洞察，如果删除不必要的单元，速度会更快，但如果项目中使用的所有单元都显式添加到dpr中，而不是通过另一个单元隐式添加时依赖搜索路径来查找它们，则速度也会更快。

I stronlgy不同意Mason和Rob的观点：这确实会有所不同

减少依赖性

---

正如梅森和罗伯所解释的那样，这种差异并不存在于当前项目中。相反，区别在于你的下一个项目。如果将不必要的（服务器）单元保留在（客户机）单元中，那么在另一个项目中使用该客户机单元也会引入依赖项。如果没有其他合理的客户机单位用于刚刚引入的单位，那么您添加了膨胀。

实际上，我认为您的意思是建议使用ICARUS在代码中查找未使用的单位。来自同一家公司。这很公平，但有两件事需要记住。首先，他特别提到了项目中其他地方使用的单元。显然你说的是对的，但它不在问题的范围之内。第二，依赖性膨胀不是什么大问题，因为智能链接器通常可以完全删除未使用的单元，除非它在初始化部分中有，在这种情况下，它只会删除大部分未使用的单元。但是，向DPR添加文件引用的限制在哪里？我的意思是你没有添加标准的VCL类的类和对话框。第三方组件或自有组件如何？我的项目很大，我仍然需要fast codeinsight。根据经验，我在dpr中添加了所有不属于VCL/安装的第三方组件的单元。这些都是图书馆的路径。其他所有内容都被明确地添加，这样您就不需要搜索路径了。当然，YMMV，特别是如果你