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

C++ naming: read_input() vs. readInput()

提问by user855

Which naming convention is more preferable in C++? The underscoremethod or the camelCasemethod? I have coded in Java for a while and I am used to the camelCase naming conventions. Which one is more prevalent?

在 C++ 中哪种命名约定更可取？该下划线方法或驼峰方法？我已经用 Java 编码了一段时间，我已经习惯了驼峰命名法。哪一种比较普遍？

Also, while defining a class, is there any preferred ordering of private/public/protected variables/methods?
Are friends usually put in the end?
What about typedefs, do they come at the top of the class definition?

另外，在定义类时，是否有私有/公共/受保护变量/方法的首选顺序？
朋友通常放在最后吗？
typedef 怎么样，它们是否位于类定义的顶部？

回答by GManNickG

I prefer to take the boost route, and match the standard library. That means lower_case_names. I like that my code reads consistent with respect to the STL.

我更喜欢走boost路线，匹配标准库。这意味着lower_case_names。我喜欢我的代码读取与 STL 一致。

回答by Adam W

This is all very subjective, but generally for C++ I do:

这都是非常主观的，但通常对于 C++ 我这样做：

camelCasefor functions and variables.

camelCase对于函数和变量。

PascalCasefor classes.

PascalCase为类。

public:
protected:
private:

In classes.

在课堂上。

Edit: Forgot these 2:

编辑：忘记了这两个：

Yes, friendat the end, typedefeither at the beginning if they are used in the class, or after if they use the class (for obvious reasons).

是的，friend最后，typedef如果它们在类中使用，则在开始时，或者如果它们使用类（出于显而易见的原因）之后。

回答by Hernán

I usually respect the traditions of the platform/environment I'm programming in, except on multiplatform C/C++ projects where I'm neutral. When programming C++ for Win32 platform, I tend to use the hungarian-notation for variables (type or semantic-prefixes). When programming MFC m_ member variables, etc. The only thing that I cannot get easy in my eyes is the Unix/POSIX open_device_driverconvention versus openDeviceDrivercamelcase style.

我通常尊重我正在编程的平台/环境的传统，除了我是中立的多平台 C/C++ 项目。在为 Win32 平台编程 C++ 时，我倾向于对变量（类型或语义前缀）使用匈牙利符号。在对 MFC m_ 成员变量等进行编程时。在我看来，唯一让我难以理解的是 Unix/POSIXopen_device_driver约定与openDeviceDriver驼峰风格。

回答by bta

The most important thing here is that you stay consistent. If you are incorporating other people's code into your project, stick with whatever method they were using. If you are planning on contributing this code to, say, an open-source software project in the future, try to abide by their coding conventions. If you are writing all of your own code from scratch, I would say stick with the conventions that you are accustomed to using. This will especially help when you come back to your code later and try to understand what you wrote.

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

Regarding structure/class access specifications, you will typically see public members listed first, followed by protected then private (in order of increasing access control). This is done mainly for readability reasons. When other people are using your code it will be these public members that they will be interfacing with, so placing them at the top of the declaration makes them easier to find. Ordering members in this fashion keeps the most likely to be used information closest to the top. I don't see friendused all too often, so I can't recall any patterns as to its usage. typedefusually appears at the top so that when looking through the rest of the class, the reader already has an understanding of your custom types (also for readability reasons, typedefs are typically grouped together and not interspersed with member declarations).

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

There are a number of existing coding conventions out there in common use, and the one thing they have in common is a standard. Whatever system you go with, even if you define it yourself, it helps if you have a document (or a page of example code) outlining the coding convention. Consistency improves readability, especially when you are revisiting older code at some time in the future.

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

Here are a couple coding conventions to perhaps give you some ideas:

以下是一些编码约定，或许可以为您提供一些想法：

• Linux kernel coding style
• OpenTracker coding guidelines
• Google's C++ style guide
• id Software's C++ coding conventions
  (December 2017: the pdf with coding conventions is no longer available.)
• Rice University coding standard

• Linux内核编码风格
• OpenTracker 编码指南
• Google 的 C++ 风格指南
• id Software 的 C++ 编码约定
  （2017 年 12 月：带有编码约定的 pdf 不再可用。）
• 莱斯大学编码标准

回答by dice

underscores are often more prevalent on unix or cross platform code.

下划线通常在 Unix 或跨平台代码中更为普遍。

windows code tends to be camel cased

Windows 代码往往是驼峰式的

generally public, protected, private is what i would expect - but maybe that is more from my C# time.

通常公共、受保护、私有是我所期望的 - 但也许这更多是来自我的 C# 时代。

回答by Thomas Bonini

I use underscores for local variables; ALL_UPPERCASE for macros and constants; camelCase for nothing and CamelCase for everything else.

我对局部变量使用下划线；ALL_UPPERCASE 用于宏和常量；camelCase 一无所有，CamelCase 为其他一切。

I always use structs and never classes, and thus start with public: (without specifying it) and then put private: at the end.

我总是使用结构而不是类，因此从 public: （不指定它）开始，然后将 private: 放在最后。

This is all very subjective and there is no right or wrong answer.

这都是非常主观的，没有正确或错误的答案。

回答by justin

Which naming convention is more preferable in C++? The `underscore' method or the camelCase method? I have coded in Java for a while and I am used to the camelCase naming conventions. Which one is more prevalent?

在 C++ 中哪种命名约定更可取？“下划线”方法还是驼峰法？我已经用 Java 编码了一段时间，我已经习惯了驼峰命名法。哪一种比较普遍？

I'd say 'just stick with what you know on this if you are starting to write your own libraries', they are both used regularly.

我会说“如果你开始编写自己的库，就坚持你所知道的”，它们都经常使用。

Also, while defining a class, is there any preferred ordering of private/public/protected variables/methods?

另外，在定义类时，是否有私有/公共/受保护变量/方法的首选顺序？

This varies by programmer/team. I order by category. I use a category for 'internal/private methods', and that category is generally second to last (the last being prohibited implementation).

这因程序员/团队而异。我按类别订购。我使用“内部/私有方法”的类别，该类别通常是倒数第二（最后一个被禁止实现）。

Are friends usually put in the end?

朋友通常放在最后吗？

I use them rarely; I insert them above the dependency (method), otherwise, after the constructor/destructor category.

我很少使用它们；我将它们插入依赖项（方法）之上，否则，在构造函数/析构函数类别之后。

What about typedefs, do they come at the top of the class definition?

typedef 怎么样，它们是否位于类定义的顶部？

That is where I put them.

那就是我把它们放的地方。

If you want to get into details, there are publicly available coding conventions. Since you already have a Java background, you'll easily be able to cut through the 'taste' in them.

如果您想了解详细信息，可以使用公开的编码约定。由于您已经具有 Java 背景，因此您将能够轻松地切入其中的“品味”。

回答by user1276700

Decades of coding as a job gave my fingers some disease. Whenever I use my little finger to press the [SHIFT] key for capital letter, I feel mild pain.

几十年的编码工作给我的手指带来了一些疾病。每当我用小指按大写字母的【SHIFT】键时，我会感到轻微的疼痛。

So I came to prefer snake_notation. Using AutoHotKey utility, I assigned [alt]+[space] combination to 'underscore character' of snake. It is little uncomfortable for my thumb to press [alt], but better than using little finger. (Actually [ctrl]+[space] is much better, but VisualStudio uses this combination as intellisense.) Also, I feel it is faster than camelCase.

所以我开始更喜欢snake_notation。使用 AutoHotKey 实用程序，我将 [alt]+[space] 组合分配给蛇的“下划线字符”。我的拇指按 [alt] 有点不舒服，但比用小指好。（其实[ctrl]+[space]要好很多，但是VisualStudio用这个组合作为intellisense。）另外，我觉得比camelCase快。

I desire i-rocks launches new keyboard with 'underscore key' for programmers who prefer snake_notation.

我希望 i-rocks 为喜欢蛇形符号的程序员推出带有“下划线键”的新键盘。