当前位置：文江博客话题详情

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

发布于 2024-08-11 18:58:05 字数 186 浏览 4 评论 0原文

C++ 中哪种命名约定更可取？ 下划线方法还是camelCase方法？我已经用 Java 编写了一段时间，并且习惯了驼峰命名约定。哪一种更流行？

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

昔梦 2024-08-18 18:58:05

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

回复收藏 0 原文

故人爱我别走 2024-08-18 18:58:05

这都是非常主观的，但通常对于 C++，我会使用：

用于函数和变量的驼峰命名法。

用于类的 PascalCase。

public:
protected:
private:

在课堂上。

编辑：忘记了这些2：

是的，friend在最后，typedef要么在开头，如果它们在类中使用，要么在它们使用类之后（对于明显的原因）。

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

camelCase for functions and variables.

PascalCase for classes.

public:
protected:
private:

In classes.

Edit: Forgot these 2:

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

回复收藏 0 原文

掩于岁月 2024-08-18 18:58:05

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

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

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

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

Linux 内核编码风格
OpenTracker 编码指南
Google 的 C++ 风格指南
id 软件的 C++ 编码约定
（2017 年 12 月：包含编码约定的 pdf 版本不再可用。）
莱斯大学编码标准< /a>

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 friend used all too often, so I can't recall any patterns as to its usage. typedef usually 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).

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

回复收藏 0 原文

在风中等你 2024-08-18 18:58:05

我通常尊重我正在编程的平台/环境的传统，除了我保持中立的多平台 C/C++ 项目。当为 Win32 平台进行 C++ 编程时，我倾向于使用匈牙利表示法来表示变量（类型或语义前缀）。在编写 MFC m_ 成员变量等时，我眼中唯一不太容易的是 Unix/POSIX open_device_driver 约定与 openDeviceDriver 驼峰风格。

回复收藏 0 原文

差↓一点笑了 2024-08-18 18:58:05

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

Windows 代码往往是驼峰式的，

一般是公共的、受保护的、私有的，这是我所期望的——但也许这更多是从我的 C# 时代开始的。

回复收藏 0 原文

夏日落 2024-08-18 18:58:05

数十年的编码工作让我的手指患上了一些疾病。每当我用小指按大写字母的[SHIFT]键时，我都会感到轻微的疼痛。

所以我开始更喜欢snake_notation。使用 AutoHotKey 实用程序，我将 [alt]+[space] 组合分配给 Snake 的“下划线字符”。我的拇指按[alt]有点不舒服，但比用小指好。（实际上[ctrl]+[space]要好得多，但VisualStudio使用这个组合作为智能感知。）而且，我觉得它比camelCase更快。

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

回复收藏 0 原文

不即不离 2024-08-18 18:58:05

对于我自己的项目，我采用了 Apple 编码约定。在编写大量 Objective-C 代码期间，我逐渐喜欢上了编写良好的 Objective-C 代码和 Cocoa 库的自记录性质。

因此，在 C++ 中，我一直坚持这些约定的精神，因为在我看来，它们提高了可读性，并且在某些情况下，正确命名也有助于我思考代码需要做什么。

SCREAMING_SNAKE_CASE：

FRAMES_PER_SECOND

PascalCase：

ClassName

camelCase：

descriptiveMethodName()

positionX

下划线：

_isGameOver

私有/受保护/公共：

私有:

protected:

public:

Apple 约定示例：

清晰和简洁都很重要，但绝不能为了简洁而牺牲清晰。

bgColor(r, g, b, a)

虽然需要多打字，但清晰度的提高通常是值得的。

backgroundColorWithAlpha(red, green, blue, alpha)

避免使用含糊不清的名称。

有太多的例子无法提及这一点，但请考虑几乎所有教程中的介绍性代码示例。有意义的名称可以提高清晰度并减少程序员的错误。

i vs index
x vs meaningfulName
posX vs positionX

我知道像 i、x、j 和 hWPTR 这样的名称有历史原因，但在我看来没有理由这样做，而且它们对教学来说很糟糕。

Microsoft 代码示例（永远复制和重复）是最严重的违规者之一。

szStr
oObj

严重地？！

当然，当与团队合作时，我很乐意采用任何标准。我希望我的代码看起来像属于该项目。唯一让我有点抽搐的是奇怪的牙套。

K&R 牙套是唯一正确的牙套。 :)

bool hasComponents() {
    ....
}

For my own projects I have adopted the Apple Coding Conventions. During my time writing a decent amount of Objective-C code I came to love the self documenting nature of well written Objective-C code and the Cocoa library.

So in C++ I have stuck with the spirit of these conventions because in my opinion they improve readability and on several occasions getting the name right also helped me think through what the code needs to do.

SCREAMING_SNAKE_CASE:

FRAMES_PER_SECOND

PascalCase:

ClassName

camelCase:

descriptiveMethodName()

positionX

Underscore:

_isGameOver

Private/Protected/Public:

private:

protected:

public:

Apple Convention Examples:

Clarity and brevity are both important, but clarity should never be sacrificed for brevity.

bgColor(r, g, b, a)

A little more typing to do but the increase in clarity is usually worth it.

backgroundColorWithAlpha(red, green, blue, alpha)

Avoid names that are ambiguous.

There are too many examples to mention of this, but consider the introductory code examples from nearly any tutorial. Meaningful names increase clarity and reduce programmer error.

i vs index
x vs meaningfulName
posX vs positionX

I understand there are historical reasons for names like i, x, j, and hWPTR but in my opinion there is no reason to do them and they are awful for teaching.

Microsoft code examples (copied and repeated forever) are some of the worst offenders.

szStr
oObj

Seriously?!

Of course when collaborating with a team I am happy to adopt whatever the standard is. I want my code to look like it belongs to the project. The one thing that does make me twitch a little are weird braces.

K&R braces are the only correct braces. :)