c++ 的首选命名约定是什么？答案

【问题标题】：What is the preferred naming conventions du jour for c++?c++ 的首选命名约定是什么？
【发布时间】：2008-12-11 22:10:43
【问题描述】：

查看 boost 库和 stl，然后查看人们的示例，我感到很困惑。似乎大写的类型名称都穿插着全小写，用下划线分隔。

这些天应该怎么做？我知道 .NET 世界有自己的一套约定，但它似乎与 C++ 领域完全不同。

【问题讨论】：

【解决方案1】：

你打开了多少蠕虫。

C++ 标准库对所有内容都使用 underscore_notation，因为这是 C 标准库使用的。

因此，如果您希望您的代码在整体上看起来一致（并且实际上不使用外部库），这是唯一的方法。

您会看到 boost 使用相同的符号，因为他们的库通常会被考虑用于未来的标准。

除此之外，还有许多约定，通常使用不同的符号来指定不同类型的符号。通常将 CamelCase 用于自定义类型，例如类和 typedef，而 mixedCase 用于变量，专门用于区分这两者，但这肯定不是通用标准.

还有 Hungarian Notation，它进一步区分了特定的变量类型，尽管仅提及该短语可能会引起一些编码人员的敌意。

作为一名优秀的 C++ 程序员，最好的答案是采用您所沉浸的代码中使用的任何约定。

【讨论】：

我推荐阅读匈牙利符号。 +1 到 Apps Hungarian Notation，-1 到 Systems Hungarian Notation（看看我能否让人们阅读这篇文章）
@dribeas：我最近偶然发现了那篇文章，我同意你的看法。我必须消除我对基于系统多样性的任何匈牙利符号的反射仇恨。
@Harper: 是的，但 real 匈牙利表示法可能很有用：[[ double mLengthOfFootballField = 109.7, umHumanHairGrowthPerDay = 400; ]] 您可以通过混合前缀来检测不良表达： [[ mpsDecentRate = ftAltitudeDelta / sTimeDelta; //

【解决方案2】：

没有好的答案。如果您正在与现有代码库集成，那么匹配他们的风格是有意义的。如果您正在创建一个新的代码库，您可能需要建立简单的指导方针。

【讨论】：

【解决方案3】：

这会因图书馆和组织而异。

例如，对于我正在构建的开发人员实用程序库，我将包含各种约定风格的友好包装模块。因此，例如，MFC 包装器模块对成员使用“m_typeMemberVariable”表示法，而 STL 包装器模块使用“member_variable”。我正在尝试构建它，以便使用的任何前端都将具有该类型前端的典型样式。

拥有通用风格的问题在于，每个人都必须同意，并且（例如）对于每个讨厌匈牙利符号的人，有些人认为不使用匈牙利符号会降低代码可理解性的基本价值.所以短期内不太可能有一个通用的 C++ 标准。

【讨论】：

【解决方案4】：

找到你觉得舒服的东西并坚持下去。某种形式的风格总比没有风格好，不要太拘泥于其他库是如何做到的。

FWIW 我使用 Google C++ 风格指南（稍作调整）。

【讨论】：

我不喜欢 Google C++ 风格指南 - 它建议避免使用异常之类的功能，这只是糟糕的编码实践（当然，这可能是您的修改之一，我不知道）
公平地说，它并没有真正建议避免异常。它只是承认，因为它们有一个非异常安全的代码库，所以在新代码中开始使用它们会很昂贵：“如果我们不得不从头开始，事情可能会有所不同”。
也就是说，IMO 可以将使用异常的代码逐渐放入不安全的代码库中，只要您对哪些 API 可以抛出异常有严格规定，并且您提供异常- 在必要时捕获适配器 API。但我可以理解为什么任何公司都不想承受这种痛苦。