如何将常见的C ++命名约定与库的命名约定进行协调

Question

大多数C ++命名约定规定使用camelCaseIdentifiers：以类的大写字母开头的名称（Person，Booking）和以字母和小写字母开头的名称变量（getPrice()，isValid()，largestValue）。这些建议与C ++库的命名约定完全不一致，后者涉及类的小写名称（string，set，map，fstream）和{{1方法和字段（names_joined_with_an_underscore，find_first_of，lower_bound，reverse_iterator）。使图片更加复杂的是操作系统和C库函数，它们涉及C和Unix中的压缩小写名称以及Windows中以大写字母开头的函数。

因此，我的代码很乱，因为一些标识符使用C ++库，C或操作系统命名约定，而其他标识符使用规定的C ++约定。编写包装库功能的类或方法很痛苦，因为类似的东西以不同的名称结尾。

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

Answer 1

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

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

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

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Answer 2

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

我慢慢看到这些约定转移到生产代码中，但这是对抗MFC命名约定的斗争，这些约定在很多地方仍然存在。

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

Answer 3

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

Answer 4

在谈到代码风格时，我往往是一个完美主义者，这一直困扰着我。我希望有一个普遍的标准，但没有。在我的职业生涯中，我发现只要个别项目的程序员是一致的，那就是你所希望的最好的。

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

Answer 5

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

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

Answer 6

老实说，我会按原样使用库并坚持自己的编码风格。你可以包装它，但这看起来有点矫枉过正。

Answer 7

Fav quote ::

  

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

我的建议是采用最常见于公司代码中的库的约定（可能是C ++库，我相信也可以提升），并使 成为您的标准。否则，你可能根本就没有。

Answer 8

好吧，既然我们无法改变标准库的实现方式，我想我们将不得不忍受它。至于协调 - 虽然前一段时间写了一些Win32 API的东西，我尝试在PascalCasing中命名我自己的方法，因为它是在API中完成的，但它感觉不对。所以我回去在camelCase中命名我的方法。我同意这是一个烂摊子，但另一个选择是使你的风格适应你使用的每个新框架或库，然后你提到的问题是在一个项目中使用不同的约定有多个库。所以我的建议是 - 坚持自己的方法和课程的感觉。或者 - 在企业环境中 - 坚持您公司的最佳实践和指南。

Answer 9

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

Answer 10

你应该接受差异。

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

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