C ++中的函数名称:是否大写?[关闭]


74

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

我来自Java环境,因此我通常会这样命名:

myFunction(...) {
}

我看过C ++中的混合代码,

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

正确的方法是什么?

另外,类方法和非类方法是否都一样?


谢谢大家 我将使用myFunction(),因为这是我习惯的
做法

所有人都认为没有“正确”的方法。但我强烈建议您避免使用下划线,因为这会使函数名称更难以阅读。我的个人风格是FunctionName,因为它简洁明了,而idk对我来说却不太那么令人讨厌。
MarcusJ

2
我个人更喜欢snake_casecamelCase因为在函数名称中有首字母缩略词的情况下(例如,您具有解析XML数据的函数),我发现parse_xml_data它比parseXMLData...更具可读性。使用时,XML和Data似乎变成一个单词camelCase
tjwrona1992

2
@ tjwrona1992,使用camelCase而不用大写所有缩写字母是常见的标准,因此在您的示例中,通常会使用parseXmlData
johnbakers

Answers:


43

没有“正确的方法”。尽管有一些约定,但它们在语法上都是正确的。您可以按照Google样式指南进行操作,尽管还有其他方法。

从说的指南:

常规功能混合大小写;访问器和更改器匹配变量的名称:MyExcitingFunction(),MyExcitingMethod(),my_exciting_member_variable(),set_my_exciting_member_variable()。


30
有一种标准的方法...所有标准库代码中使用的标准命名约定是my_name,但MACRO_NAMES或TemplateParameterTypeNames除外。这是从unix C约定派生的。驼峰式保护套是从Microsoft c和c ++代码派生的约定。CamelCase更难以阅读。
2011年

8
匈牙利表示法来自Microsoft。TitleCase和camelCase较老,并且已在计算之外用于替代snake_case。
布伦特·浮士德

6
其实有一种“正确的方法”。更具体地说,有一种“不正确的方式”。即,如果要使您的类与基于范围的for-loop一起使用则必须定义称为begin和的函数end。C ++不支持PascalCase此功能。
埃莱2015年

1
@catphive我同意微软似乎在c ++中使用了驼峰式的情况。微软开发人员网络也为骆驼箱提供了一个相当具体和清晰的布局。话虽如此,但我看到它经常被以小写首字母命名的函数所误用,根据微软的说法,这是函数参数变量名。尽管没关系,但我在本网站和其他网站上对此一无所知。我个人再一次发现Microsoft代码在视觉上最吸引人,如果我敢说我发现任何代码在视觉上确实很吸引人。至少丑陋。
元帅工艺

同样,我认为微软比其他任何软件公司都更加统一和加速了计算机的使用和普及。Google在开放源代码方面做了大量工作,比Microsoft最初定义的要多,但我不同意仅开放源代码就值得很多。Microsoft提供了许多智能框架工作,以指导专有和开源软件。如果不是该协议可以一起工作,互联网将不是今天的样子。他们智能地统一了硬件,这是其他公司无法企及的。甚至他们似乎再也做不到。
法警艇艇

47

从C ++ 11开始,您可能要对函数名使用snake_case或。camelCase

这是因为要使一个类在基于范围的for循环中作为范围表达式工作,您必须定义称为begin和的函数。end为该类(区分大小写)。

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


3
我不同意。您可以将PascalCase用于您的方法,然后将开始/结束名称用于需要它的特定类。这与您从具有不同命名习惯的第三方继承结构的方式完全一样。
Dess

9
@Dess:是的,但是最终的混合效果并没有改善。因此,如果您开始一个新项目,建议不要使用PascalCase作为函数名称。

我同意@Dess
Lucas Martins

3
另外,由于全局函数main位于中lowerCamelCase,因此我至少要对全局函数名称进行投票。
endavid

28

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

但是,老实说,这仅仅是指导。最重要的一点是在整个代码库中保持一致。选择看起来自然/对您有用的东西,并坚持下去。如果您要加入正在进行的项目,请遵循其标准。


1
这就是我正在使用的东西,但是名称空间呢?有不是很奇怪std::vector但是Project::Connection::TcpHandler吗?
rr-

1
仅当您要向std添加内容时。否则,请保持内部一致。

16

我在生产代码中看到的最常见的是(按此顺序):

myFunctionName     // lower camel case

MyFunctionName     // upper camel case

my_function_name   // K & R ?

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

例如,前Java程序员倾向于将小写驼峰函数用作函数


13

如果看标准库,模式通常是my_function,但是每个人似乎都有自己的方式:-/


1
为什么这没有上升。标准库从字面上告诉您大多数语言的代码风格标准。
Erik Aigner

6
xkcd.com/927和“关于标准的
伟大之处

1
《 C ++核心准则》对此进行了说明:“首选underscore_style名称。使用下划线分隔名称的一部分是C和C ++的原始样式,并在C ++标准库中使用。该规则是默认值,仅在您有选择时使用通常,您别无选择,必须遵循既定风格来保持一致性。一致性的要求胜过个人品味。这是对您没有约束或更好的主意的建议。” 见github.com/isocpp/CppCoreGuidelines/blob/master/...
迈克尔Franzl

11

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

但是,如果我不得不为此辩护,我会说这种区别远不只是美学。当您遇到临时的函数式构造时,它节省了一点点思想。与此相反,您可以辩称,是否实际并不重要Foo(1,2,3)调用函数-如果它是构造函数,则其作用就像一个函数,无论如何都要按值返回Foo。

该约定还避免了C ++继承具有相同名称的类的功能,而这并不是一个错误的惨败,因为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;
}

毕竟,酒吧既是名词又是动词,因此可以合理地在一个地方将其定义为类,在另一个地方将其定义为函数。显然,有避免冲突的更好方法,例如正确使用名称空间。就像我说的,确实是因为我更喜欢使用小写首字母的功能,而不是因为实际上有必要将它们与类区分开来。


5

我认为这是偏爱,尽管我更喜欢 myFunction(...)


5

与Java不同,C ++没有“标准样式”。我曾经工作过的几乎所有公司都具有自己的C ++编码风格,并且大多数开源项目也都具有自己的风格。您可能需要查看一些编码约定:

有趣的是,C ++编码标准通常会指定不使用语言的哪些部分。例如,《 Google C ++样式指南》说“我们不使用C ++例外”。我工作过的几乎所有地方都禁止使用C ++的某些部分。(一个地方我的工作基本上是说,“在C程序,但newdelete是没关系”!)


1
“用C编写程序,但是可以使用new和delete进行操作”-这将打开一大堆蠕虫,只是键入Foo *foo = new Foo;而不是Foo *foo = malloc(sizeof(Foo)); assert(foo);;-)
Steve Jessop

是的,这就是重点。在那家公司,我们几乎总是使用new和delete而不是malloc和free。其他实际上只是C的东西:不允许构造函数,方法,模板或异常。他们正在构建嵌入式软件,并且担心他们可能需要移植到没有C ++编译器的平台上(这已经差不多15年了)。
劳伦斯·贡萨尔维斯

1
听起来像对我的帽子一样疯狂。如果他们担心自己可能需要一个没有C ++的平台,他们可以编写C,并从中受益,通过对其进行编译,-std=c89 -pedantic他们实际上可以将其验证为C89,它将在C编译器中运行,而不是C ++,这可能不。如果他们想这样拼命地键入“新”和“删除”,使用几个宏(当然你需要额外的括号:delete(new(TYPE));不是delete new TYPE;
史蒂夫·杰索普

我从未说过这是个好习惯。我仅以作为例子说明“ C ++的禁止部分”类型的编码约定可以达到的极端程度。
劳伦斯·贡萨尔维斯

4

正如其他人所说,C ++中没有这样的东西。话虽如此,我倾向于使用编写标准库的样式-K&R。

另外,请参阅Bjarne Stroustrup的FAQ条目


“ K&R”是一种缩进样式,而不是大写样式,因此这不能回答问题。请参见en.wikipedia.org/wiki/Indentation_style#K&R_style另外,该链接已断开。现在位于此处:stroustrup.com/bs_faq2.html#Hungarian。但是,Stroustrup在此处写道:“我更喜欢使用下划线将标识符(例如element_count)中的单词分开,而不是使用诸如elementCount和ElementCount之类的替代方式。”
Michael Franzl

3

只要您与开发人员保持一致,就可以按照自己的意愿进行操作。组。惯例每隔几年就会发生变化.....(remmeber nIntVAr)...


3

语言没有太多的“正确”方法。这是个人喜好或团队的标准。在编写自己的代码时,通常会使用myFunction()。此外,您没有提到的C ++经常会出现的样式是my_function()-没有大写字母,下划线而不是空格。

确实,它只是由您工作的代码决定的。或者,如果这是您自己的项目,那么您自己的个人喜好。


2

这一切都取决于您对正确的定义。您可以通过多种方式评估编码风格。可读性(对我而言)很重要。这就是为什么我会使用my_function编写函数名和变量名的方式。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.