大多数 C++ 命名约定规定使用camelCaseIdentifiers: 以大写字母开头的类名称 ( Person, Booking) 和以小写字母开头的字段和变量名称 ( getPrice(), isValid(), largestValue)。这些建议与 C++ 库的命名约定完全不一致，后者涉及类 ( string, set, map, fstream) 和names_joined_with_an_underscore方法和字段 ( find_first_of, lower_bound, reverse_iterator, first_type) 的小写名称。更复杂的是操作系统和 C 库函数，它们涉及 C 和 Unix 中的压缩小写名称以及 Windows 中以大写字母开头的函数。
结果我的代码一团糟，因为一些标识符使用 C++ 库、C 或操作系统命名约定，而其他标识符使用规定的 C++ 约定。编写包装库功能的类或方法是痛苦的，因为类似的事物以不同风格的名称结尾。
那么，您如何协调这些不同的命名约定呢？
Diomidis，我和你一样痛苦，多年来我一直在不同方案之间切换，试图找到适用于我使用的不同库/框架（MFC 和/或 STL/Boost）的东西。在使用单个框架（例如 STL）时，您可以尝试复制它使用的命名约定，但是当您引入不同的框架时，它很容易分崩离析。
最后，我为我编写的所有新代码采用了单一样式（基于 Google C++ 样式指南），并在适当的时候重构旧代码以使用这种样式。你不能很容易地协调不同的命名约定，所以不要浪费时间去尝试。为您的团队/部门/公司实施一个方案并坚持下去 - 但不要担心在使用混合方案时代码看起来有多“丑陋”。
恕我直言，Google C++ 指南非常好 - 有一些小的修改。在此处查看指南：
采用 C++ 的一种方式naming_convention，这是当今文献中大多数代码示例所做的。
我慢慢看到这些约定进入生产代码，但这是与在许多地方仍然盛行的 MFC 命名约定的斗争。
与旧标准作斗争的其他风格差异是使用尾随下划线而不是m_表示成员。
为什么需要调和？只要代码可以编译，并且您可以完成工作，就不用担心。
在代码风格方面，我往往是一个完美主义者，这一直困扰着我。我希望有一个通用标准，但没有。在我的职业生涯中，我发现只要单个项目的程序员保持一致，那就是你所希望的最好的。
归根结底，我认为它归结为知道方法、对象或函数来自哪个库。如果您知道这一点，那么就很容易记住该库使用的约定，假设该项目不包含很多库。我已经尝试调整自己的代码以匹配我使用的库的代码，但它始终是一个移动的目标，最后只是令人沮丧。
在我正在从事的项目中，我遵循我的项目的代码约定。当我调用其他东西时，我使用该库的 API。
我还要补充一点，库的包装是一个坏主意（我正在处理的代码库中有很多），因为它通常由解决自己问题的开发人员完成，并且通常不适合使用由所有其他开发人员。另一方面，高质量的包装是昂贵的。
老实说，我会按原样使用库并坚持自己的编码风格。你可以把它包起来，但这似乎有点矫枉过正。
最喜欢的报价::
关于标准的最好的事情是有这么多可供选择！
我的建议是采用贵公司代码中最常出现的库约定（可能是 C++ 库，我相信 boost 也坚持使用它），并将其作为您的标准。否则，您可能根本就没有。
好吧，既然我们不能改变标准库的实现方式，我想我们将不得不忍受它。至于调和 - 不久前在编写一些 Win32 API 的东西时，我尝试在 PascalCasing 中命名我自己的方法，就像在 API 中完成的那样，但感觉不对。所以我回到用 camelCase 命名我的方法。我同意这是一团糟，但另一种选择是使您的样式适应您使用的每个新框架或库，然后您提到的问题是在单个项目中拥有多个使用不同约定的库。所以我的建议是——坚持你自己的方法和类的感觉。或者 - 在企业环境中 - 坚持贵公司的最佳实践和指导方针。
我似乎记得很久以前读过他们故意使标准库与推荐的编码约定不同，以避免命名冲突。但是，我现在找不到任何提到这一点的参考资料。我记得读过你不应该在类型名称中使用前导小写字母，因为它们是为标准库保留的。我认为使用下划线也会发生类似的事情。我真的不认为多个命名约定是一个问题，因为它清楚地将标准代码与项目中的代码分开。我总是在我的项目中使用大写驼峰式大小写类型和小驼峰式大小写方法/成员来编写代码。我现在的工作场所除了类型之外还使用大写的骆驼案例来表示方法，这让我非常恼火。但是，他们也喜欢匈牙利疣，
你应该接受差异。
当人们看到 remove_copy_if 的使用时，他们会立即知道这是一个算法。这实际上是一个积极的特征，因为算法带有某些保证（或缺乏）。
我们还为我们自己的自定义算法使用命名约定。