C++ 中的函数名：是否大写？ [关闭]答案

【问题标题】：Function names in C++: Capitalize or not? [closed]C++ 中的函数名：是否大写？ [关闭]
【发布时间】：2009-11-21 18:24:27
【问题描述】：

在 C++ 中命名函数的约定是什么？

我来自 Java 环境，所以我通常会这样命名：

myFunction(...) {
}

我见过 C++ 中的混合代码，

myFunction(....)
MyFunction(....)
Myfunction(....)

正确的方法是什么？

另外，类方法和非类方法一样吗？

【问题讨论】：

谢谢大家。我会使用 myFunction()，因为这是我习惯的
没有“正确”的方法，都是意见。但我强烈建议您避免使用下划线，这会使函数名称更难阅读。我个人的风格是 FunctionName，因为它简洁，而且对我来说不那么讨厌。
我个人更喜欢snake_case 而不是camelCase，因为在函数名称中有首字母缩写词的情况下（假设你有一个解析XML数据的函数）我发现parse_xml_data比parse_xml_data更具可读性parseXMLData... XML 和数据在使用camelCase时似乎变成了一个单词的一个词组@
@tjwrona1992 使用 camelCase 而不将缩写的所有字母大写是常见的标准，因此在您的示例中通常使用 parseXmlData
每当我看到大写的函数名，我都觉得它在喊。所以当我看到一整页大写的函数和函数调用时，我能说什么。我只能引用“(a) K&R 是对的，(b) K&R 是对的”。

标签： c++ function coding-style naming-conventions

【解决方案1】：

从 C++11 开始，您可能希望使用 snake_case 或 camelCase 作为函数名称。

这是因为要使一个类作为range-based for-loop 中的范围表达式工作，您have to 为该类定义了名为begin 和end（区分大小写）的函数。

因此，使用例如PascalCase 用于函数名称意味着如果您需要使类与基于范围的 for 一起使用，则必须打破项目中的命名一致性。

【讨论】：

我不同意。您可以将 PascalCase 用于您的方法，然后为需要它的特定类使用开始/结束名称。这与您从具有与您自己不同的命名约定的第三方的结构子类化完全相同。
@Dess：是的，但最终的组合并没有让它变得更好。因此，如果您开始一个新项目，建议您不要使用 PascalCase 作为函数名称。
我同意@Dess
另外，由于全局函数main 在lowerCamelCase 中，所以我会给它一个额外的投票，至少对于全局函数名称。
@endavid main 不比蛇形大写骆驼大写。

【解决方案2】：

没有“正确的方法”。它们在语法上都是正确的，尽管有一些约定。你可以关注Google style guide，虽然还有其他人。

来自上述指南：

正则函数有大小写混合；访问器和修改器匹配变量的名称：MyExcitingFunction()、MyExcitingMethod()、my_exciting_member_variable()、set_my_exciting_member_variable()。

【讨论】：

有一个标准的方式...所有标准库代码中使用的标准命名约定是my_name，除了MACRO_NAMES，或TemplateParameterTypeNames。这源自 Unix C 约定。 Camel case 是源自 microsoft c 和 c++ 代码的约定。 CamelCase 更难阅读。
匈牙利符号来自微软。 TitleCase 和 camelCase 更古老，并已在计算之外用作 snake_case 的替代方案。
其实有一个“正确的方法”。或者更具体地说，有一种“不正确的方式”。也就是说，如果你想让你的类使用基于范围的for-loop，you have to define functions called begin and end。 C++ 在此不支持PascalCase。
@catphive 我同意微软似乎在 C++ 中使用了驼峰式大小写。微软开发者网络也为骆驼案提供了相当具体和清晰的布局。也就是说，我看到它经常被第一个字母小写的函数命名误用，根据微软的说法，这是用于函数参数变量名称。虽然这并不重要，但我在这个网站和其他网站上对此感到不满。我个人再次发现 Microsoft 代码在视觉上最吸引人，如果我敢说我发现任何代码在视觉上真的很吸引人。它最不丑。
在我看来，我再次发现微软比任何其他软件公司更能统一和加速计算机的使用和采用。谷歌在开源方面做了很多，比微软更原始，但我不同意开源代码本身就很有价值。 Microsoft 提供了许多智能框架来指导专有和开源软件。如果没有协议一起工作，互联网就不会是今天的样子。他们智能地统一了硬件，这是其他公司无法做到的。甚至他们似乎也不能再这样做了。

【解决方案3】：

我见过的大多数代码是camelCase 函数（小写首字母）、ProperCase/PascalCase 类名和（最常见的）snake_case 变量。

但是，老实说，这只是指导。最重要的一点是在您的代码库中保持一致。选择看起来自然/适合你的东西，并坚持下去。如果您要加入正在进行的项目，请遵循他们的标准。

【讨论】：

这是我正在使用的，但是命名空间呢？有std::vector 而有Project::Connection::TcpHandler 不是很奇怪吗？
仅当您向标准添加内容时。否则，请保持内部一致。
建议对命名空间使用snake_case，因为这样更容易将它们与类区分开来。我在一些风格指南中注意到了这一点，最引人注目的是 ISO CPP 核心指南和 Google 风格指南。

【解决方案4】：

我在生产代码中看到的最常见的是（按此顺序）：

myFunctionName     // lower camel case

MyFunctionName     // upper camel case

my_function_name   // K & R ?

我发现程序员在 C++ 代码中使用的命名约定通常与他们的编程背景有关。

例如ex-java 程序员倾向于对函数使用小写驼峰式

【讨论】：

【解决方案5】：

如果你看standard libraries the pattern generally is my_function，但每个人似乎都有自己的方式：-/

【讨论】：

为什么不是这样。标准库从字面上告诉您大多数语言中代码样式的标准。
xkcd.com/927 和“标准的伟大之处在于有这么多”
C++ 核心指南这样说：“首选underscore_style 名称。使用下划线分隔名称的各个部分是原始的 C 和 C++ 样式，并在 C++ 标准库中使用。这条规则仅当您有选择时才使用默认设置。通常，您别无选择，必须遵循既定的风格以保持一致性。对一致性的需求胜过个人品味。这是当您没有限制或更好时的建议想法。”见github.com/isocpp/CppCoreGuidelines/blob/master/…

【解决方案6】：

就函数而言，我个人更喜欢thisStyle 而不是ThisStyle。这确实是出于个人喜好，可能受 Java 影响，但我非常喜欢函数和类看起来不同。

如果我不得不为此争论，我会说这种区别不仅仅是美学上的。当您遇到临时的函数式构造时，它可以节省一点点思考。与此相反，您可以争辩 Foo(1,2,3) 是否是函数调用实际上并不重要 - 如果它是构造函数，那么它的行为与返回 Foo 值的函数完全一样。

该约定还避免了 C++ 继承的 function-with-same-name-as-a-class-is-not-an-error 惨败，因为 C 有一个单独的标记命名空间：

#include <iostream>

struct Bar {
    int a;
    Bar() : a(0) {}
    Bar(int a) : a(a) {}
};

struct Foo {
    Bar b;
};

int Bar() {
    return 23;
}

int main() {
    Foo f;
    f.b = Bar();
    // outputs 23
    std::cout << f.b.a << "\n";
    // This line doesn't compile. The function has hidden the class.
    // Bar b;
}

毕竟，Bar 既是名词又是动词，因此可以合理地定义为一个地方的类和另一个地方的函数。显然有更好的方法来避免冲突，例如正确使用命名空间。所以正如我所说，这实际上只是因为我更喜欢带有小写首字母的函数的外观，而不是因为实际上有必要将它们与类区分开来。

【讨论】：

【解决方案7】：

与 Java 不同，C++ 没有“标准风格”。我工作过的几乎所有公司都有自己的 C++ 编码风格，大多数开源项目也有自己的风格。您可能想要查看的一些编码约定：

GNU Coding Standards（主要是 C，但提到了 C++）
Google C++ Style Guide
C++ Coding Standards: 101 Rules, Guidelines, and Best Practices

有趣的是，C++ 编码标准经常指定语言的哪些部分不使用。例如，Google C++ Style Guide 说“我们不使用 C++ 异常”。我工作过的几乎所有地方都禁止使用 C++ 的某些部分。（我工作的一个地方基本上说，“用 C 编程，但 new 和 delete 还可以”！）

【讨论】：

"C 中的程序，但新建和删除都可以" - 这会打开一大堆蠕虫，只需输入 Foo *foo = new Foo; 而不是 Foo *foo = malloc(sizeof(Foo)); assert(foo); ;-)
嗯，是的，这就是重点。在那家公司，我们几乎总是使用 new 和 delete 而不是 malloc 和 free。除此之外，它实际上只是 C：不允许构造函数、方法、模板或异常。他们正在构建嵌入式软件，并担心可能需要移植到没有 C++ 编译器的平台（这几乎是 15 年前的事了）。
对我来说听起来很疯狂。如果他们担心他们可能需要一个没有 C++ 的平台，他们可以编写 C，并获得通过使用-std=c89 -pedantic 编译它的好处，他们实际上可以将其验证为 C89，它将在 C 编译器中工作，而不是 C++ ，这可能不是。如果他们非常想键入“new”和“delete”，请使用几个宏（诚然，您需要额外的括号：delete(new(TYPE)); 而不是 delete new TYPE;。
我从来没有说过这是一个好的约定。我只是把它作为一个例子来说明“C++ 的禁止部分”类型的编码约定可以变得多么极端。

【解决方案8】：

我认为这是一个偏好问题，虽然我更喜欢myFunction(...)

【讨论】：

【解决方案9】：

正如其他人所说，C++ 中没有这样的东西。话虽如此，我还是倾向于使用标准库的编写风格——K&R。

另外，see the FAQ entry by Bjarne Stroustrup。

【讨论】：

"K&R" 是缩进样式，不是大写样式，所以这不是回答问题。请参阅en.wikipedia.org/wiki/Indentation_style#K&R_style 另外，链接已损坏。现在位于：stroustrup.com/bs_faq2.html#Hungarian。然而，Stroustrup 在那里写道：“我更喜欢使用下划线来分隔标识符（例如 element_count）中的单词，而不是使用其他选项，例如 elementCount 和 ElementCount。”

【解决方案10】：

做你想做的，只要你在你的开发中是一致的。团体。每隔几年，约定就会改变......（记住 nIntVAr）......

【讨论】：

【解决方案11】：

对于这种语言并没有太多“正确”的方式。这更多的是个人喜好或团队的标准。当我编写自己的代码时，我通常使用 myFunction()。此外，在 C++ 中经常看到的一种您没有提到的样式是 my_function() - 没有大写字母、下划线而不是空格。

实际上，这只是由您使用的代码决定的。或者，如果这是您自己的项目，那么您自己的个人喜好。

【讨论】：

【解决方案12】：

这完全取决于您对正确的定义。您可以通过多种方式评估您的编码风格。可读性是一个重要的（对我来说）。这就是为什么我会使用my_function 编写函数名和变量名的方式。

【讨论】：