Delphi 在Uses子句中使用完全限定的名称空间是否有好处？

在uses子句中完全限定名称空间是否更好？例如，这些声明中有一个比另一个好吗

uses
  ShellApi,
  Windows,
  SHFolder,
  SysUtils;

uses
  Winapi.ShellApi,
  Winapi.Windows,
  Winapi.SHFolder,
  System.SysUtils;

---

这取决于你在建什么。如果它是一个简单的VCL应用程序，就像Delphi最有名的那样，那么您通常不需要担心它。但是，如果您正在构建一个包，例如使用组件，那么您需要确保清楚地定义要使用的环境：VCL或FMX。Embarcadero添加了名称空间前缀，以便能够区分不同的可能解决方案

但是，在大多数情况下，

仅用作视觉表示。它可以帮助编码人员识别您正在使用的库

比如说。如果不在项目选项中添加名称空间前缀或名称空间，DelphiIDE/编译器将不接受一个非常通用的单元。标准的

Graphics

单元需要明确定义为

Vcl.Graphics

，而不是

FMX.Graphics

另一方面，使用完整名称空间对于许多来自其他严格执行该名称空间的语言的编码人员来说是很舒服的，不仅如此，还允许您一眼就能看到所有内容的本质，而无需在其他地方查找有关您实际使用的内容的更多信息

编辑

---

此外，我最近看到，使用完全限定的名称空间也有助于加快编译速度，因为编译器不必尝试解析所有名称空间。

完全限定名称的主要好处是可以将代码成功编译到项目中，不考虑这些项目的命名空间前缀设置

这为什么有用？如果您正在编写应用程序代码，那么您可能知道并控制包含特定单元的项目的名称空间前缀设置。但是，如果您正在编写库代码，即打算包含在您无法控制的项目中的代码，则无法预测这些项目中的名称空间前缀。如果未完全限定单元名称，则会对使用库代码的任何项目的项目设置施加约束。库代码不应该这样做

---

因此，总而言之，对于应用程序代码，如果您喜欢不太详细的名称，可以合理地省略名称空间限定符。对于库代码，应使用完全限定的名称以允许库代码独立

只是想告诉大家使用完全限定的名称空间如何帮助加快构建过程。因此，在7gen i7上，平均6秒钟编译32万行代码。使用完全限定的名称空间，代码平均可在6秒钟内编译。因此，如果有一个优势的话，那就是在ms中。在一台较旧的计算机上，同一个项目平均在14秒内编译32万行代码。使用完全限定的单元名，代码在14秒内编译。@EdijsKolesnikovičs感谢您的测试。这只是我看到一些开发人员提到的东西，而且很有意义，所以添加了它。当然，它不会影响单个设备上的秒数。那个单位的LOC不重要。想象一下，许多单元的

uses

子句中有很多东西。我并不是说它会以秒的速度加速，但总的来说，考虑到Delphi最著名的编译速度，对于整个项目来说，快半秒仍然是值得注意的。重要的是文件系统。PS-我与1000多万LOC合作。