5
您应该在哪里放置常数，为什么？
在大多数大型应用程序中，通常只有几个“常量”位置： 一类用于GUI和内部内容的内容（制表页标题，组框标题，计算因子，枚举） 一类用于数据库表和列（此部分是生成的代码）以及它们的可读名称（手动分配） 一类应用程序消息（日志，消息框等） 在这些类中，常量通常分为不同的结构。在我们的C ++应用程序中，仅在.h文件中定义常量，而在.cpp文件中分配值。 优点之一是，所有琴弦等都放在一个中央位置，每个人都知道在必须更改某些内容时可以在哪里找到它们。 这尤其是项目经理在人们来来往往时喜欢的东西，这样每个人都可以更改这些琐碎的事情，而不必深入研究应用程序的结构。 另外，您可以轻松地一次更改相似的“组框” /“选项卡页”等的标题。另一个方面是，您可以仅打印该类并将其交给非程序员，该非程序员可以检查字幕是否直观，向用户发送的消息是否太详细或太混乱等。 但是，我看到了某些缺点： 每个类都与常量类紧密耦合 添加/删除/重命名/移动常量需要重新编译至少90％的应用程序（注意：至少在C ++中，不需要更改值）。在我们的一个带有1500个类的C ++项目中，这意味着大约7分钟的编译时间（使用预编译的标头；如果没有它们，则大约为50分钟），再加上大约10分钟的链接到某些静态库。 通过Visual Studio编译器构建速度优化的发行版最多需要3个小时。我不知道是否大量的类关系是源，但也有可能。 您会被迫将临时硬编码的字符串直接转化为代码，因为您想非常快速地测试某项内容，并且不想仅等待15分钟来进行该测试（并且可能以后每次测试）。每个人都知道“以后我会解决”的想法。 在另一个项目中重用一个类并不总是那么容易（主要是由于其他紧密的耦合，但是常量处理并没有使它更容易。） 您将在哪里存储这样的常量？为了使您的项目经理相信还有更好的概念也符合上面列出的优点，您还会提出什么论点？ 随意给出特定于C ++或独立的答案。 PS：我知道这个问题是主观的，但是老实说，我不知道有比这个网站更好的地方。 有关此项目的更新 关于编译时间，我有个新闻： 在Caleb和gbjbaanb的帖子中，有空时，我将常量文件拆分为其他几个文件。我最终还将我的项目分成几个库，现在可以轻松得多。在发布模式下进行编译显示，包含数据库定义（表，列名等-超过8000个符号）并建立了某些哈希值的自动生成的文件在发布模式下造成了巨大的编译时间。 现在，通过停用包含DB常量的库的MSVC优化器，我们可以将发布模式下的项目（几个应用程序）的总编译时间从最多8小时减少到不到一小时！ 我们还没有找到为什么MSVC很难优化这些文件，但是现在，由于我们不再只依赖夜间构建，因此此更改减轻了很多压力。 这个事实以及其他好处，例如紧密耦合少，可重用性更好等，也表明花时间拆分“常量”并不是一个坏主意；-) 更新2 由于这个问题仍然受到关注： 这是过去几年中我一直在做的事情： 将每个常量，变量等完全放在与其相关的范围内：如果仅在单个方法中使用常量，则可以在该方法中定义它。如果单个类对此感兴趣，请将其保留为该类的私有实现细节。这同样适用于名称空间，模块，项目，公司范围。我还将相同的模式用于助手功能等。（如果您开发一个公共框架，这可能不会100％适用。） 这样做可以提高可重用性，可测试性和可维护性，使您不仅花费更少的时间（至少在C ++中），而且花费在错误修复上的时间也更少，这使您有更多的时间实际开发新功能。同时，开发这些功能的速度会更快，因为您可以更轻松地重用更多代码。这在一定程度上胜过中央常量文件可能具有的任何优势。 如果您想了解更多，请特别看一下接口隔离原则和单一职责原则。 如果您同意，请支持Caleb的回答，因为此更新基本上是他所说的更一般的看法。