问题标签 [file-organization]

无论出于何种原因，我们公司都有一个编码指南，其中规定：

Each class shall have it's own header and implementation file.

因此，如果我们编写一个名为的类，MyString我们将需要关联的MyStringh.h和MyString.cxx。

还有其他人这样做吗？有没有人看到任何编译性能的影响？10000 个文件中的 5000 个类的编译速度是否与 2500 个文件中的 5000 个类一样快？如果不是，差异是否明显？

[我们编写 C++ 代码并使用 GCC 3.4.4 作为我们的日常编译器]

我习惯于在一个 C 文件中完成所有编码。但是，我正在从事一个足够大的项目，以至于这样做变得不切实际。我一直将它们#include 在一起，但我遇到过我多次#include 某些文件的情况，等等。我听说过 .h 文件，但我不确定它们的功能是什么（或者为什么有 2 个文件比 1) 好。

我应该使用什么策略来组织我的代码？是否可以将特定文件的“公共”功能与“私人”功能分开？

这个问题引发了我的询问。tea.h 文件不引用tea.c 文件。编译器是否“知道”每个 .h 文件都有对应的 .c 文件？

目前，我将图像（最大 6MB）作为 BLOB 存储在 InnoDB 表中。随着数据量的增长，每晚备份的速度越来越慢，阻碍了正常的性能。

因此，二进制数据需要进入文件系统。（指向文件的指针将保存在数据库中。）

数据具有树状关系：

现在我希望数据通过目录结构均匀分布。我应该如何做到这一点？

我想我可以尝试MD5('userId, albumId, imageId');对结果字符串进行切片以获取我的目录路径：

这将允许我将第一个字符映射到服务器并将目录结构均匀地分布在多个服务器上。

然而，这不会保持每个用户的图像组织，可能会将 1 个相册的图像分布在多个服务器上。

我的问题是：
将图像数据以平衡的方式存储在文件系统中，同时将用户/相册数据保存在一起的最佳方法是什么？

我在思考正确的方向吗？或者这完全是错误的做事方式？

更新：
我将md5(user_id)在最高级别进行字符串切片。然后将所有用户数据放在同一个桶中。这将确保数据的均匀分布，同时将用户数据存储在一起。

我想我会使用从后面拆分的 albumId（我喜欢这个主意！）以保持每个目录的专辑数量更小（尽管对于大多数用户来说这不是必需的）。

谢谢！

我正在使用 SyncToy 1.4，它可以满足我的需要，除了：

• 它无法处理系统之间分配的驱动器号更改（例如同步 USB 驱动器），
• 它将自己的（隐藏的）文件留在正在同步的文件夹中（这是 OS/FS 的限制吗？），
• 它为已删除的文件夹重新创建空文件夹，
• 它会同步已从同步中取消选择的文件夹中的新子文件夹
• 有时会发现所有文件都已更改，而它们仍然与原来相同。
• 它无法处理很长的文件路径/名称

SyncToy 2.1 太慢而无法使用。特别是在没有任何更改的文件夹上再次运行时，它将从头开始扫描所有文件和子文件夹以查找差异。

它必须是一个不使用基于 Internet 的存储的解决方案，因为这并不总是可用的，否则可能会太慢。我更喜欢不会将自己的文件添加到要同步的文件夹中的东西，以及可以快速轻松地更改文件和文件夹同步选择的东西。运行时交互性越少越好，理想情况下，只需单击几下鼠标就可以安全地同步多个文件夹对（就像 SyncToy 一样）。

我必须使用 rsync 和批处理文件吗？带有GUI的东西可以让奶奶轻松使用，会更好。这是我的标准：

1. 不需要 Internet 连接。

2. 它不能在源或目标中创建它自己的管家文件/文件夹（也许因为 NTFS 的缺点而必须这样做？）

3. 测试：具有两个非空子文件夹 A 和 B 的源文件夹。将子文件夹 B 移动到子文件夹 A 中，它是否在目标文件夹中复制了这个？

4. 测试：重命名子文件夹 A 中的文件，它是否在目标文件夹中重复？

5. 只需单击一两次鼠标，是否可以同时完成多个文件夹对同步？

6. 它是否具有预览即将进行的更改的选项？

7. 它是否允许轻松更改源和/或目标路径？

8. 它必须很快，（特别是如果重新扫描两个文件夹树而没有任何改变）。

9. 测试：在 PC 1 上同步 USB 驱动器，然后将文件和文件夹从 USB 驱动器复制到 PC 2，在 PC 2 上更改文件夹和文件（PC 1 上的文件夹和文件保持不变），在 PC 2 上同步 USB 驱动器，然后重新同步USB 驱动器中 PC 1 上的文件和文件夹。它可以做到这一点而没有任何错误吗？

10. 不包括安装，奶奶用起来舒服吗？-->

我喜欢组织我的代码，所以理想情况下我希望每个文件一个类，或者当我有非成员函数时，每个文件一个函数。

原因是：

1. 当我阅读代码时，我总是知道应该在哪个文件中找到某个函数或类。

2. 如果每个头文件是一个类或一个非成员函数，那么我 include在头文件时不会包含一团糟。

3. 如果我对一个函数做一个小的改动，那么只有那个函数需要重新编译。

但是，将所有内容拆分为许多头文件和许多实现文件会大大减慢编译速度。在我的项目中，大多数函数访问一定数量的模板化其他库函数。这样代码将被一遍又一遍地编译，每个实现文件一次。目前在一台机器上编译我的整个项目需要 45 分钟左右。大约有 50 个目标文件，每个目标文件都使用相同的昂贵编译头文件。

也许，每个头文件有一个类（或非成员函数）是否可以接受，但是将许多或所有这些函数的实现放入一个实现文件中，如下例所示？

同样，优点是我可以仅包含 foo 函数或仅包含 bar 函数，并且整个项目的编译会更快，因为foobar.cpp是一个文件，所以std::vector<int>（这只是其他一些昂贵的示例compile 模板化构造）必须只编译一次，而不是如果我单独编译 afoo.cpp和两次bar.cpp。当然，我上面的理由 (3) 不适用于这种情况：在更改 foo(){...} 之后，我必须重新编译整个可能很大的 file foobar.cpp。

我很好奇你的意见是什么！

我将项目定义为包含主干、分支、标签子目录的 SVN 目录。

在确定何时将项目拆分为两个或将多个项目合并为一个时，您使用什么标准？ - 每个“项目”一个应用程序，具有用于公共源和资源的共享项目？- 一个包含应用程序所有源和资源的大“项目”？

单项目或多项目都有其优点和缺点。我们正朝着一个单一的项目迈进，我正试图弄清楚这是否是正确的方法。

拆分项目允许更好地控制套件的不同部分如何合并更改。公共库可以是版本，不同的应用程序可以选择使用特定版本（maven dep 管理方法）。

拆分项目还会创建多个类层次结构，使代码整体更难理解，并可能导致代码重复。我认为适当设计整体结构和组件之间的关系将是管理此成本的关键。

统一的项目方法将使开发人员在设置工作空间方面更容易，并提供单一的类层次结构。这是一把双刃剑，因为它还会向开发人员提供更多信息（太多类无法理解）。

所以，当你试图决定在哪里合并和在哪里拆分时，你使用什么经验法则？

如果在标题（* .h）内，是否有必要#include使用此文件中定义的类型？

例如，如果我使用 GLib 并希望gchar在头文件中定义的结构中使用基本类型，是否有必要执行 a #include <glib.h>，知道我的 *.c 文件中已经有了它？

如果是，我还必须将它放在#ifndefand之间#define或之后#define？

我首先想说我已经阅读了 Subversion 手册。我读过这个问题。我也读过这个问题。这是我的困境。

假设我有 3 个存储库，布局如下：

• 数据访问对象/
  • 分支机构/
  • 标签/
  • 树干/
    • 数据访问对象/
    • DataAccessObjectTests/
• 平面对象/
  • 分支机构/
  • 标签/
  • 树干/
    • 平面对象/
    • 计划对象测试/
• WinFormsPlanViewer/
  • 分支机构/
  • 标签/
  • 树干/
    • WinFormsPlanViewer/

PlanObject 和 DataAccessObject 存储库包含共享项目。它们由 WinFormsPlanViewer 使用，但也由其他几个存储库中的几个其他项目使用。

在这里忍受我。我在 WinFormsPlanViewer/trunk 文件夹上放了一个 svn:externals 定义，如下所示：

这是我在进行 svn 更新后看到的。

• WinFormsPlanViewer/
  • 分支机构/
  • 标签/
  • 树干/
    • WinFormsPlanViewer/
    • 对象/
      • 数据访问对象/
      • DataAccessObjectTests/

PlanObject 的东西甚至没有在更新中出现！我不知道这是否与它有关，但 PlanObject/trunk 文件夹上也有一个外部定义：

这里发生了什么？我究竟做错了什么？当 PlanObject 也使用 svn:externals 引用 DataAccessObject 时，使用 svn:externals 从 WinFormsPlanViewer 引用 PlanObject 和 DataAccessObject 会产生不良后果吗？

我们公司有一个 Oracle 10g 数据库（一个巨大的），我根据员工的要求为他们提供数据。我的问题是，我几乎保存了我写的每一个 SQL 查询，现在我的列表变得太长了。我想组织和重命名这些 .sql 文件，以便我可以轻松找到我想要的文件。目前，我正在使用一些名为Sales Dept, Field Team, Planning Dept, Specialetc 的文件夹，在这些文件夹下有 .sql 文件，如

我尝试根据文件的内容命名文件，但这会使文件名更长，并且不能完全满足我的需要。有时有人来要求特别报告，我给文件起名，但这也不太好。我知道重复或非常相似的文件会随着时间的推移而增长，但我无法控制它们。

你能告诉我正确的方向来重命名所有这些文件和文件夹并组织我的查询以便更容易和更好地控制吗？TIA。

假设我们有几个扩展异常的异常类。我的问题是，为了正确组织我们的文件，这些类应该放在哪里？

ie - 他们是助手类吗？

有一个存档吗？行。尊重命名约定。行。

但是然后我们将这些文件分组，我们应该将它们放在哪个文件夹中？在名为 Helper Classes 的文件夹上？

你可以随意命名，我意识到，我只是想弄清楚，如果我们可以放置这些类的地方有什么合理的地方。

提前致谢， MEM