您如何协调常见的 C++ 命名约定与库的命名约定答案

【问题标题】：How do you reconcile common C++ naming conventions with those of the libraries您如何协调常见的 C++ 命名约定与库的命名约定
【发布时间】：2008-12-08 18:36:35
【问题描述】：

大多数 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++ 约定。编写包装库功能的类或方法是一件痛苦的事，因为类似的事物以不同风格的名称结尾。

那么，您如何协调这些不同的命名约定？

【问题讨论】：

标签： c++ coding-style naming-conventions

【解决方案1】：

Diomidis，我和你一样痛苦，多年来我一直在不同方案之间切换，试图找到适用于我使用的不同库/框架（MFC 和/或 STL/Boost）的东西。在使用单个框架（例如 STL）时，您可以尝试复制它使用的命名约定，但是当您引入不同的框架时，它很容易分崩离析。

最后，我为我编写的所有新代码采用了单一样式（基于 Google C++ 样式指南），并在适当的时候重构旧代码以使用这种样式。你不能很容易地协调不同的命名约定，所以不要浪费时间去尝试。为您的团队/部门/公司实施一个方案并坚持下去 - 但不要纠结于使用混合方案时代码看起来有多“丑陋”。

恕我直言，Google C++ 指南非常好 - 有一些小的修改。在此处查看指南：

https://google.github.io/styleguide/cppguide.html#Naming

【讨论】：

我正在考虑使用类似于 Google 指南的东西，但它们与 STL 不能很好地混合，这就是我问这个问题的原因。我想我被 Java 的绝对顺序给宠坏了。
如果我有幸在“纯”STL 中进行开发，那将不是问题。我经历了一个根据目标框架使用多种样式的阶段——很好，直到我开始将 STL/boost 与 MFC 混合！ Google 的风格和我见过的一样好，虽然我稍微调整了一下。
除非您想全部更改，否则不要重命名旧代码 - 您使用 diff/merge 搞砸了，这可能会造成伤害。
当我阅读了他们关于不使用异常的建议时，我开始对这些建议持怀疑态度，我就像“他们在想，真的吗？”

【解决方案2】：

采用 C++ naming_convention 的一种方式，这是当今文献中大多数代码示例所做的。

我慢慢看到这些约定进入生产代码，但这是与在许多地方仍然盛行的 MFC 命名约定的一场战斗。

与旧标准作斗争的其他风格差异是使用尾随下划线而不是m_ 来表示成员。

【讨论】：

C++ 命名约定的所有标识符（类和字段名）都是小写的。你能指出推荐这种风格的 C++ 风格指南吗？ “C++ 编码标准”和“C++ 风格的元素”书籍没有。
我不知道有这样的文档，我从 STL（显然是标准的一部分）派生了 C++ 命名约定。
我同意 Motti 的观点：虽然我更喜欢 camelCase 风格，但 STL 使用的是命名约定，因此可以被认为是 C++ 的“默认”风格......但是 Win32 API/. NET 是 PascalCase，而 C API 都是关于六长有趣的函数名......所以，最后，拿起你的毒药...... ^_^
使用 C++ 标准库命名约定的一个优点是您自己的容器类类变得更容易与 STL 容器兼容。例如，您可以在具有push_back() 的类上使用back_insert_iterator，但不能在具有pushBack() 的类上使用。

【解决方案3】：

为什么需要调和？只要代码编译好了，你就可以完成工作，不用担心。

【讨论】：

因为对某些人（比如我）来说，成为程序员的部分乐趣在于代码的美学。我的代码是诗，只要我能做到这一点而不影响手头的任务。
使用不同的代码约定，您必须记住标识符的来源，以便正确输入。
是的，但是在处理其他人的代码和第 3 方库时，他们不可能拥有与您（以及彼此）相同的约定，所以在某些时候您必须坚持下去，得到习惯了，然后完成一些工作。
Diomidis Spinellis 在另一个评论线程中提到他被 Java 中的绝对命名约定宠坏了。在被 Java 和 Ruby 严格的命名约定宠坏后，我也有同样的问题。正如我们在这里所了解的那样，C++ 是一种难以协调的约定的混搭。
作为开发人员，我们将大部分时间用于阅读代码。惯例使我们工作的这一部分更省时、更安全。无法将这些约定强加到 3rd 方库不是问题：您几乎不会阅读/调试该 3rd 方库代码。如果第 3 方的库接口语义有冲突，您可以调整或在代码中留下注释。在处理其他人的代码时，约定是使他们遵守与您相同的规则的原因。

【解决方案4】：

在代码风格方面，我往往是一个完美主义者，这一直困扰着我。我希望有一个通用标准，但没有。在我的职业生涯中，我发现只要单个项目的程序员保持一致，那就是你所希望的最好的。

归根结底，我认为它归结为知道方法、对象或函数来自哪个库。如果您知道这一点，那么就很容易记住该库使用的约定，假设该项目不包含很多库。我已经尝试调整自己的代码以匹配我使用的库的代码，但它始终是一个移动的目标，最终只会令人沮丧。

【讨论】：

【解决方案5】：

在我从事的项目中，我遵循我的项目的代码约定。当我调用其他东西时，我使用该库的 API。

我还要补充一点，包装库是一个坏主意（我正在处理的代码库中有很多），因为它通常由解决自己问题的开发人员完成，并且通常是不适合所有其他开发人员使用。另一方面，高质量的包装很昂贵。

【讨论】：

【解决方案6】：

老实说，我会按原样使用库并坚持自己的编码风格。您可以包装它，但这似乎有点过头了。

【讨论】：

【解决方案7】：

最喜欢的报价::

关于标准的最好的事情是有很多选择！

我的建议是采用贵公司代码中最常出现的库约定（可能是 C++ 库，我相信 boost 也坚持使用该库），并将设为您的标准。否则，您可能根本就没有。

【讨论】：

【解决方案8】：

好吧，既然我们不能改变标准库的实现方式，我想我们将不得不忍受它。至于调和——在不久前编写一些 Win32 API 的东西时，我尝试在 PascalCasing 中命名我自己的方法，就像在 API 中所做的那样，但感觉不对。所以我回到用 camelCase 命名我的方法。我同意这是一团糟，但另一种选择是使您的样式适应您使用的每个新框架或库，然后您提到的问题是在单个项目中拥有多个使用不同约定的库。所以我的建议是——坚持你自己的方法和类的感觉。或者 - 在企业环境中 - 坚持贵公司的最佳做法和准则。

【讨论】：

Nitpick：我不相信“camelCase”这个词被广泛用于区分首字母的小写和大写。请参阅：en.wikipedia.org/wiki/Camelcase。我不经常看到 PascalCase 这个词——不知道它的一般含义是什么。
@Steve：你读过你链接到的那篇维基百科文章吗？因为一开始它就提到了骆驼格和帕斯卡格的区别，说它是“某些人”使用的。好吧，我就是其中之一。
这里有一个很好的参考 MSDN 上的套管样式：msdn.microsoft.com/en-us/library/x2dbyw72(VS.71).aspx
Doh - 我浏览得太快了。在其他阅读中，我看到我的经验（camelCase 作为更通用的术语）并不是最常见的。这就是我吹毛求疵的结果。 :)

【解决方案9】：

我似乎记得很久以前读过他们故意使标准库与推荐的编码约定不同，以避免命名冲突。但是，我现在找不到任何提到这一点的参考资料。我记得读过你不应该在类型名称中使用前导小写字母，因为它们是为标准库保留的。我认为使用下划线也会发生类似的事情。我真的不认为多个命名约定是一个问题，因为它清楚地将标准代码与项目中的代码分开。我总是在我的项目中使用大写驼峰式大小写类型和小驼峰式大小写方法/成员来编写代码。我现在的工作场所除了类型之外还使用大写的骆驼案例来表示方法，这让我非常恼火。但是，他们也喜欢连 MS 都否认的匈牙利疣：P

【讨论】：

【解决方案10】：

你应该接受差异。

当人们看到 remove_copy_if 的使用时，他们会立即知道这是一个算法。这实际上是一个积极的特征，因为算法具有某些保证（或缺乏）。

我们还为自己的自定义算法使用命名约定。

【讨论】：