你如何协调普通的C ++命名约定和库的命名约定

大多数C ++命名约定规定使用camelCaseIdentifiers :以类( PersonBooking )的大写字母开头的名称和以字母和variables( getPrice()isValid()largestValue )的小写字母开头的名称。 这些build议与C ++库的命名约定完全不一致,它们涉及类( stringsetmapfstream )的小写名称和方法和字段( find_first_oflower_boundreverse_iteratorfirst_type )的first_type 。 使图片更加复杂的是操作系统和C库函数,它们涉及在C和Unix中压缩的小写字母名称,以及在Windows中以大写字母开头的函数。

因此,我的代码是一团糟,因为一些标识符使用C ++库,C或操作系统命名约定,而其他标识符使用规定的C ++约定。 编写包装库function的类或方法是很痛苦的,因为类似的东西会以不同风格的名字结尾。

那么,你如何调和这些不同的命名约定呢?

采用C ++ naming_convention一种方法是,现在大多数naming_convention代码示例都是这样做的。

我慢慢地看到这些约定转移到生产代码中,但是这对于许多地方仍然盛行的MFC命名约定是一场战斗。

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

Diomidis,我分享你的痛苦,多年来花了很多时间在不同的scheme之间切换,试图find一些适用于我使用的不同库/框架(MFC和/或STL / Boost)的东西。 在使用单个框架(如STL)时,可以尝试复制它使用的命名约定,但是当您引入不同的框架时,它很容易分崩离析。

最后,我为所有新编写的代码(基于Google C ++风格指南)采用了单一样式,并在适当的时候重构旧代码以使用此样式。 你不能很容易地调和不同的命名约定,所以不要浪费时间尝试。 为你的团队/部门/公司实施一个scheme并坚持下去 – 但是不要挂上使用混合scheme时代码的“丑陋”。

谷歌C + +指导方针是相当不错的恕我直言 – 一些小的修改。 检查指南在这里:

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

为什么需要调和? 只要代码编译完成,就可以完成工作,不用担心。

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

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

收录

关于标准的最好的事情是,有这么多的select!

我的build议是最常采用公司代码中出现的图书馆约定(可能是C ++库,我相信这也是推动的重点),并将其作为您的标准。 否则,你可能还没有一个。

在我正在进行的项目中,我遵循我的项目的代码约定。 当我打电话给其他人时,我使用该库的API。

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

那么,因为我们不能改变标准库的实现方式,我想我们必须忍受它。 至于协调 – 前一段时间编写一些Win32 API的东西,我尝试在PascalCasing中命名我自己的方法,因为它是在API中完成的,但是这样做感觉不对。 所以我回去在camelCase中命名我的方法。 我同意这是一个混乱,但另一种select是适应你的风格,你使用的每个新的框架或图书馆,然后有一个问题,你提到有一个以上的图书馆在一个项目中使用不同的约定。 所以我的build议是 – 坚持对自己的方法和课程感觉正确。 或者 – 在企业环境中 – 坚持公司的最佳实践和指导方针。

我似乎回忆起很久以前,他们select使标准库有意地与推荐的编码惯例不同,以避免命名冲突。 但是,现在我找不到任何提及这个的提法。 我记得读过,你不应该在types名称中使用前导小写字母,因为它们是为标准库保留的。 我假设使用下划线正在进行类似的操作。 我真的没有看到多个命名约定成为问题,因为它将标准代码与项目中的代码分开。 我总是在我的项目中使用大写骆驼事件types和较低的骆驼事件来处理方法/成员。 我目前的工作场所除了使用types之外,还使用资本骆驼案例,这让我非常沮丧。 但是,他们也喜欢匈牙利的疣,甚至连MS也不同意:P

老实说,我只是使用这个库,并坚持自己的编码风格。 你可以把它包起来,但这似乎是矫枉过正。

你应该拥抱不同。

当人们看到使用remove_copy_if时,他们会立即知道这是一个algorithm。 这实际上是一个积极的function,因为algorithm有一定的保证(或缺乏)。

我们也使用自定义algorithm的命名约定。