如果我的uses
子句尽可能小,我个人喜欢它,但在许多应用程序中,真正的大单元(就膨胀可执行文件而言)喜欢Forms
或VirtualTrees
至少在另一个单元中需要。
uses
所以:即使最终没有从项目中删除任何单元,如果我清理我的条款是否会有所不同?如果真是这样,那么是以哪种方式?并且:清理uses
条款是应该尽快完成还是可以等到我偶然发现一个未使用的单元?
如果我的uses
子句尽可能小,我个人喜欢它,但在许多应用程序中,真正的大单元(就膨胀可执行文件而言)喜欢Forms
或VirtualTrees
至少在另一个单元中需要。
uses
所以:即使最终没有从项目中删除任何单元,如果我清理我的条款是否会有所不同?如果真是这样,那么是以哪种方式?并且:清理uses
条款是应该尽快完成还是可以等到我偶然发现一个未使用的单元?
如果它在项目的其他地方使用,它不会有太大的不同,除了产生更易于阅读的更清晰的代码。不过,它可能会影响一些小事情。
编译顺序:编译器根据哪些单元使用哪些单元来决定编译单元的顺序。如果从早期单元的 uses 子句中删除一个单元,这可能会导致在编译周期的后期编译使用的单元。这听起来可能不多,但请记住,初始化部分的运行顺序与编译单元的顺序相同。不过,这确实不应该对您的项目产生太大影响。
CodeInsight:当您拉起代码完成下拉菜单时,它将根据当前可用的所有单元提供选择。您可以通过减少您使用的单位数量来减少它必须过滤的选择数量 - 从而减少将血腥的东西拉起来所需的时间!(不,我不苦。你为什么问?)
一般没有。如果一个单元在项目中的任何地方使用过一次,那么再使用多少次并不重要。相反,如果一个单位在某个地方至少使用过一次,那么从多少个地方移除它并不重要。编译后的程序将表现相同,并且大小大致相同。
唯一的区别在于单元初始化和完成部分的顺序。单元使用顺序会影响这些部分的执行顺序,尽管从未记录过确切的效果(所以尽量不要依赖初始化顺序)。
但是我仍然鼓励你清理你的单元列表,出于同样的原因鼓励你清理你的变量列表和参数列表。当您摆脱不需要的东西时,阅读您保留的代码会更容易,因为您可以合理地确信您正在阅读的内容可以准确地了解代码的作用。如果您的代码提到了一堆单元但从未真正使用它们,那么下次您或其他人查看代码时,您将花费一些时间尝试找到您的代码使用这些设施的地方那些单位。(你会对自己说,“嗯,这段代码包括Graphics
,但我看不到它在哪里绘制任何东西。我最好再看看,因为我认为这段代码没有任何类似的职责。嘿,同事——你能抽出一些时间告诉我这个单位在哪里画东西吗?”)
是的,有一个技巧经常被忽视并且可能会在后面咬你:
如果有一些初始化/完成代码,即使在你的单元中没有调用其他代码(并且单元总是包含在内) ,它也会始终执行。虽然你认为它不会)。因此,删除项目中不需要的单元可能会产生显着差异。
另一件值得注意的事情是,当在 2 个不同的单位中存在同音异义词时,单位的顺序决定了编译器选择的标识符,并且您在不使用单位名称前缀的情况下调用它们(作为最佳实践,您应该始终这样做)。
除此之外,正如 Mason 和 Rob 所指出的,单元顺序会影响它们的编译顺序以及初始化/完成的顺序。
至于代码洞察力,如果您删除不必要的单元会更快,但如果您在项目中使用的所有单元都显式添加到 dpr,而不是在通过另一个隐式添加时依赖搜索路径来查找它们,那么全局也会更快单元。
我非常不同意 Mason 和 Rob:它确实有所作为!
减少依赖。
正如 Mason 和 Rob 所解释的,不同之处不在当前项目中。相反,不同之处在于您的 NEXT 项目。如果您在(客户端)单元中保留不必要的(服务器)单元,那么在另一个项目中使用该客户端单元也会引入依赖项。如果刚刚引入的单位没有其他合理的客户单位,那么你已经增加了膨胀。
使用免费的 Pascal Analyzer 找出代码中未使用的单元。