C++命名:read_input()与readInput()

use*_*855 16 c++ naming-conventions

在C++中哪种命名约定更可取?该下划线方法或驼峰方法?我用Java编写了一段时间,我已经习惯了camelCase命名约定.哪个更普遍?

此外,在定义类时,是否有私有/公共/受保护变量/方法的首选顺序?
朋友通常到底放在一边吗?
那么typedef,它们是否位于类定义的顶部?

GMa*_*ckG 34

我更喜欢采用提升路线,并匹配标准库.这意味着lower_case_names.我喜欢我的代码读取与STL一致.

  • @Adam:那么为什么需要在STL代码和自己的代码之间进行光学区分呢?这对我来说没有意义,但人们在各种环境中使用它(不仅仅是C++).这就是*命名空间*的用途 - 而且它们做得非常好. (8认同)
  • 我曾经也这样做过,但是我参与的一个项目说,如果您确实使用了命名空间 std,那么有时很难立即找出您编写的代码以及来自 std:: 的代码;这对我来说很有意义,但为您点赞,因为我也喜欢这种风格。 (2认同)
  • 为什么不输入`std ::`?它解决了这个问题,并提高了可读性. (2认同)
  • @GMan:因为我无法编写其他人的代码,并且编码标准优先于我的个人喜好。 (2认同)

Ada*_*m W 20

这一切都非常主观,但一般来说对于C++我做的是:

camelCase 用于函数和变量.

PascalCase 对于课程.

public:
protected:
private:
Run Code Online (Sandbox Code Playgroud)

在课堂上.

编辑:忘记这2:

是的,friend最后,typedef如果他们在课堂上使用,或者在他们使用课程之后(出于显而易见的原因),在开始时.

  • 好吧,我一般都避开朋友:) (7认同)
  • @Steven - 我希望你不要在现实生活中使用你的朋友.8V) (3认同)
  • 关于camelCase,像`std :: vector <...>.push_back()`之类的东西是以错误的方式摩擦我的强迫症. (2认同)

bta*_*bta 7

这里最重要的是你保持一致。如果您要将其他人的代码合并到您的项目中,请坚持使用他们使用的任何方法。如果您计划将来将此代码贡献给开源软件项目,请尝试遵守他们的编码约定。如果您从头开始编写自己的所有代码,我会说坚持您习惯使用的约定。当您稍后返回代码并尝试理解您所写的内容时,这将特别有帮助。

关于结构/类访问规范,您通常会看到首先列出公共成员,然后是受保护的成员,然后是私有成员(按照增加访问控制的顺序)。这样做主要是出于可读性的原因。当其他人使用您的代码时,他们将与这些公共成员进行交互,因此将它们放在声明的顶部可以更容易找到它们。以这种方式对成员进行排序可以将最有可能使用的信息保持在最靠近顶部的位置。我不friend经常看到它的使用,所以我不记得它的使用模式。 typedef通常出现在顶部,以便在浏览类的其余部分时,读者已经了解了您的自定义类型(也是出于可读性原因,typedef通常将 s 分组在一起,而不是散布在成员声明中)。

有许多现有的通用编码约定,它们的共同点就是标准。无论您使用什么系统,即使您自己定义它,如果您有一个概述编码约定的文档(或一页示例代码)也会有所帮助。一致性提高了可读性,尤其是当您将来某个时候重新访问旧代码时。

以下是一些编码约定,也许可以给您一些想法:


Her*_*nán 6

我通常尊重我正在编程的平台/环境的传统,除了我是中立的多平台C/C++项目.编程C + raw Win32时,我倾向于使用匈牙利语表示变量(类型或语义前缀).在编写MFC m_成员变量等时,在我看来,我唯一不容易的就是Unix/POSIX open_device_driver约定与openDeviceDrivercamelcase风格.