明确将您的单位名称添加到Delphi项目源的优缺点

Question

我多年来一直在使用Delphi，我的每个项目都是从源代码编译到exe - 没有包等。如果'MyUnitA.pas'在任何地方使用，它只是在接口或实现部分声明另一个需要它的单位这一切都可以在任何地方工作，这意味着在我的项目源（dpr）中只有框架定义（在框架列表中没有出现的其他地方似乎需要）和必须调用的单元的“奇怪”定义非常早，例如madExcept，FastMM等。

我注意到XE有时会在dpr中解析东西，直到你真正编译它为止。此外，在处理包时，如果必须在没有明确添加到包中的情况下隐式提取内容，则会发出警告。这让我想知道我们是否应该努力将所有使用过的单元添加到我们的dpr（如包定义）或右键单击项目和'添加到项目'。你做什么的？

Answer 1

我个人将搜索路径留空，并在.dpr文件中包含所有单位。我认为这样做的主要优点是：

• 我确切知道我的项目中包含哪些文件。
• 查看单位（Ctrl + F12），查看表单（Shift + F12）提供项目中的所有单位和表格。

我认为这种方法没有任何明显的缺点。是的，当你包含一个新的第三方组件时，你必须将文件添加到.dpr文件中，但根据我的经验，这通常不会发生，因为它会成为一个很大的负担。

Answer 2

（在Delphi Xe3 Enterprise上进行测试）
1 000 000线项目，1000个班，300个单位

• 第一种方法：
  • 搜索路径仅包含vcl源路径
  • 项目文件中使用路径名（约300个文件）声明的所有文件
  • 我遇到了很多麻烦：
    • Delphi Ide永久挂起，任务管理器中有“100％cpu”
    • 许多带下划线的代码，主要是“找不到标识符”
    • Ctrl + Enter符号大部分时间都不起作用
    • 项目文件很难编辑，每次按键后都要等几秒钟
      
      
• 第二种方法：
  • 项目选项中的所有搜索路径（~50条路径）
  • 在项目文件中声明的所有文件没有任何路径名（大约300个文件）
  • 结果：
    • Delphi Ide中没有更多的挂钩
    • 代码中没有带下划线的标识符
    • 项目文件更具响应性
    • 编译时间更快（~10-15％）
    • 我的婆婆离开了家。
  • 缺点：
    • “在文件中查找”项目文件，无法使用，我不得不使用“在目录中搜索”
      选项。但它也会扫描不是来自我项目的文件 对我而言，这不是什么大不了的事。

Answer 3

我和大卫在一起。我们/我做的完全一样。

依赖控制是主要的好处。单位使用的明确性具有很大的优势。我从不怀疑项目来源的来源。

另一个好处是我们作为一个团队，我们从不依赖于IDE中的搜索路径。我们所有的机器都有空的搜索路径，如果我们正在努力获得控制来进行我们的出价，那么只有调试搜索路径中的项目。在GUI上工作时，我们只向IDE添加控件（这本身就很大，但实际上只是我们软件的一小部分，我们主要使用Delphi附带的控件）。我经常在之后卸载它们。最大的优势：当我需要处理一个非常旧的版本时，我可以简单地从Perforce中提取它并使用正确的Delphi编译器构建它。其他所有内容都在dproj（或者我们仍然可以编译基于D5的版本）中处理。

不依赖于IDE中的搜索路径也意味着我们的构建服务器不需要配置任何搜索路径。我们有一个实用程序可以使dproj与我们软件版本的已配置第三方库版本保持一致。我们有一个实用程序，可以从dproj / dof创建一个cfg文件。这样，无论编译器和第三方组件版本如何，我们都可以构建我们在世界任何地方仍在使用的软件的每个版本。我们可以在不改变构建服务器设置中的任何内容的情况下完成它。实际上，如果对其Perforce分支进行了更改并且甚至没有考虑它，我们每晚都会构建所有“活动”版本。

Answer 4

为每个项目添加单位名称：

• 开始一个新项目需要大量的“锅炉板”。对于短期项目来说，这是一个问题。
• 并非所有项目都在我的控制之下。我可以控制我的同事的搜索路径，因为它有一件事需要改变，但我不能控制每一个项目，因为这不再是一件事。我们只处理很少的非常大的项目，但我们经常会有很多小的实用程序或帮助项目。
• 使重构变得困难。如果我们有20个项目使用单元A，并且我们使单元A依赖于单元B，我们将需要将单元B添加到所有20个项目中。如果这20个项目由公司的5个不同的程序员管理，事情开始变得丑陋。另一方面，如果5个程序员的所有20个项目都可以通过搜索路径找到单元B，那么事情就很容易了。
• 使同一单元的多个版本变得容易，因为在克隆项目时复制了给定的单元。在我的书中，这是一件坏事。

我个人将所有“库”单元（包括第三方软件包）保存到一个受版本控制的大文件夹中。我们将此文件夹称为“工作环境”，我们有一个“激活”环境的内部工具（即：它更正了IDE的搜索路径，安装包，将内容复制到System文件夹，向Registry添加条目，甚至创建一些开始菜单快捷方式）。这对我来说非常。

Answer 5

我的方式：

• 项目选项中的相对库路径。这样可以快速编译，因为即使是最小的应用程序，IDE也不必搜索每个目录。此外，这意味着我可以在任何地方查看我的代码，它将编译。

• 仅包含项目文件中的主要表单和单位。基本上，我的胶水代码（通常是我的表格）最终在项目文件中。这可以控制我的单元依赖性，并在我重构时有所帮助。

• 在我的DUnit套件中，测试类是我的胶水代码，因此是我项目文件中唯一的代码。

相对路径对于正确管理源代码至关重要。正如我所说，你可以在任何地方检查你的代码，它仍然可以编译。我经常检查我的临时目录中的代码来执行代码峰值，或查看旧版本来编译和运行以比较事物。它实际上花了我大约2分钟来建立一个新的构建环境。

我的持续集成服务器在我的机器上作为服务运行，并检出并构建到不同的目录，并且不会干扰我的开发环境。绝对路径是不可能的。

我最终做了很多CTRL-点击代码中的标识符来导航（当代码洞察工作时，只有大约一半的时间），或者CTRL-输入单位名称......

我多年前学到的一点是，您可以在代码中的任何位置键入单位名称，然后按CTRL-Enter键，它将打开单位。显然你需要删除你最终输入的内容，但它很快！

如果您希望单位出现在ALT-F11“使用单位”对话框中，请使用DDevExtensions，该对话框将替换为包含搜索路径中所有单位的新对话框，而不仅仅是在你的项目中。仅仅是针对该功能的一个很棒的工具。

（注意：我在大型项目中使用DDevExtensions“使用单位”和相对库路径时遇到了问题。但是仍然值得尝试）

（注2：这似乎是用2.4.1修复的。哦，我的名字错了，我有IDE Fix Pack，但它实际上是DDevExtensions）

N - [

Answer 6

我在向.dpr和.dproj添加文件时发现的最大缺点是它会确保你会从许多VCS中获得“冲突”，如果你在同事的同一位置添加了B行时添加了A行，你会在两个文件中遇到冲突。它们很容易在.dpr中解决，在.dproj中更容易混淆，它通常格式不太好。 这里有一个问题，原来Delphi只使用.dpr列出文件，然后开始使用这两个文件，而恕我直言现在.dpr的use子句应该只用在任何其他源文件中，而文件列表项目中使用的只能在.dproj中保存（IDE项目管理需要真正改进，而不是变得更加混乱......）。 出于这个原因，我有1）第三方标准库的库文件夹（环境变量集是根路径，允许不同的项目使用不同的项目）2）项目库路径，文件不与其他项目共享3）只有相关的文件被添加到项目源中，主要是表单/数据模块。

Answer 7

Con：质量中心问题77687：

Editing in the .dpr source gets slower with more units in the project

  

在.dpr源代码中编辑可以非常   所有Code Insight都会变慢   选项已禁用。它变慢了   该项目有更多的单位（   单位的内容无关紧要。）

Answer 8

我使用相对搜索路径，只在dpr中放置与视觉继承相关的单位。保持项目相对性的主要原因是它可以在任何位置构建。 （并且你可以快速检查旧的东西而不会弄乱路径或子站）。对我而言，这是一个关键特征，我准备与其他小问题共存以实现这一目标。

由于我不仅使用单元文件，还使用.inc文件（对于定义和交叉编译器的兼容性），我还是需要搜索路径。

使用此设置。我只有一个问题，即在某些情况下更改项目时工作目录会卡住。并且所有（相对+项目目录）路径都相对于工作目录而不是项目。这会导致项目目录中类似单位名称出现问题，或者在具有类似设置相对路径的项目之间切换时出现问题，我无法想象它与David的设置有什么不同

所以我主要养成了在打开一个新项目之前关闭项目的习惯而File-＆gt;打开并加载来自“真实”项目的任何文件，以防万一它搞砸了。

我从未真正被重复的单位问题所困扰。显然我的基本文件卫生就足够了。 （但如果你真的害怕，一个简单的脚本可以执行检查），所以我没理由微观管理.dpr

Answer 9

经验告诉我，大卫的方式适用于所有本土代码，因为通过在项目中包含所有内容，您始终可以随时查看所有源代码，如果出现问题，您可以立即到达现场。

我多年前学到的（虽然有时候我因为懒惰而忽略了......）从我继承的一个大型项目开始学习并没有遵循这种做法 - 我花了几周时间搜索目录和网络共享以寻找'使用'我需要的单位来查看来源。

但是我没有在项目中包含来自包/组件等的单元 - 在庞大的规模上变得过于笨拙，并且你还会在那里获得各种“外来”单元，这些单元会破坏项目视图的流动等。另外 - 我宁愿看不到那些包裹中有时留下的警告...... LOL

我发现的主要缺点是，在团队开发中，除非您严格执行整个团队中所有代码的一致目录结构，否则构建可能会经常被破坏。 / p>

HTH