C ++ Style Convention：类声明中的参数名称

I'm a fairly new C++ programmer and I would like to hear the arguments for and against naming parameters within the class declaration.

我是一个相当新的C ++程序员,我想在类声明中听到支持和反对命名参数的参数。

Here's an example:

这是一个例子:

Student.h

#ifndef STUDENT_H_
#define STUDENT_H_

#include <string>

using namespace std;

class Student
{
    private:
        string name;
        unsigned int age;
        float height, GPA;

    public:
        Student(string, unsigned int, float, float);

        void setAge(unsigned int);
};

#endif /*STUDENT_H_*/

vs.

#ifndef STUDENT_H_
#define STUDENT_H_

#include <string>

class Student
{
    private:
        string name;
        unsigned int age;
        float height, GPA;

    public:
        Student(string name, unsigned int age, float height, float GPA);

        void setAge(unsigned int age);
};

#endif /*STUDENT_H_*/

Student.cpp

#include "Student.h"

Student::Student(   string name,
            unsigned int age,
            float height,
            float GPA) :

            name(name),
            age(age),
            height(height),
            GPA(GPA) {}

void Student::setAge(unsigned int age) { this -> age = age; }

I cannot decide. On the one hand, I feel that it is redundant to name the variables in both the declaration (.h) and the definition (.cpp). Especially since you have to worry about updating the names in both places so that they match. On the other hand, without names, it can often be confusing to determine what variables the parameters correspond to just by looking at the declaration.

我做不了决定。一方面,我觉得在声明(.h)和定义(.cpp)中命名变量是多余的。特别是因为您不得不担心更新两个地方的名称以使它们匹配。另一方面,没有名称,通过查看声明来确定参数对应的变量通常会令人困惑。

So, what are your thoughts?

所以你的想法是什么?

8 个解决方案

#1

It is much better to use the parameter names in the declaration, and use good parameter names. This way, they serve as function documentation. Otherwise, you will have to write additional comments in your header, and it is always better to use good parameter/variable names than to use comments.

在声明中使用参数名称要好得多,并使用好的参数名称。这样,它们就可以作为功能文档。否则,您将不得不在标题中写入其他注释,使用好的参数/变量名称总是比使用注释更好。

Exception: when a function must have a certain signature for external reasons, but the parameters are not actually used. In this case, you should not name them in the implementation either.

例外:当函数由于外部原因必须具有某个签名时,但实际上并未使用这些参数。在这种情况下,您不应该在实现中为它们命名。

#2

Put the names in both places, clarity is the reward you get for the task of maintaining the signatures in two places.

将名称放在两个地方,清晰度是您在两个地方维护签名的任务所获得的奖励。

#3

Intellisense/autocomplete/whatever similar is in development environments usually only sees the declaration and will only show it as autocomplete. So if you don't declare names in the declaration the users will not see them in autocomplete unless they go and read the source. That's perhaps tolerable, but not very convenient.

Intellisense / autocomplete /开发环境中的任何类似内容通常只能看到声明,并且只会将其显示为自动完成。因此,如果您未在声明中声明名称,则用户不会在自动填充中看到它们,除非他们去阅读源代码。这可能是可以忍受的,但不是很方便。

#4

Even if redundant, I find that it is better to have parameter names in both places. This is typically because, changing a parameter name often has semantic consequences. Missing it in the header helps screw up the documentation (which is where I tend to put most of the comments i.e. API specifications) and missing it in the implementation helps me forget what why that particular parameter has such an odd name.

即使多余,我发现在两个地方都有更好的参数名称。这通常是因为更改参数名称通常会产生语义后果。在标题中缺少它有助于搞砸文档(这是我倾向于放置大部分注释的地方,即API规范)并且在实现中缺少它有助于我忘记为什么该特定参数具有如此奇怪的名称。

The only time I forego a parameter name is when I have to implement a third party library callback and I am not using one of the parameters. Even then I'd do:

我放弃参数名称的唯一一次是我必须实现第三方库回调并且我没有使用其中一个参数。即便如此,我也会这样做:

 my_callback(int idx, Context* /*ctx*/)  { ...

so that I know the signature well.

所以我很了解签名。

#5

If you ever release your code as a librray, with associated .h file, your users will never see the definition, only the declaration, adding an exztra documentation burden on yourself.

如果您将代码作为librray发布,并使用相关的.h文件,您的用户将永远不会看到定义,只会声明,为您自己添加exztra文档负担。

#6

On the one hand, I feel that it is redundant to name the variables in both the declaration (.h) and the definition (.cpp). Especially since you have to worry about updating the names in both places so that they match.

一方面,我觉得在声明(.h)和定义(.cpp)中命名变量是多余的。特别是因为您不得不担心更新两个地方的名称以使它们匹配。

You don't need the names to match literally. The header file, which specifies the interface, works a bit like an imperfect contract (imperfect because it does not contain preconditions and postconditions, unless you write them down in comments) and a "caller's guide". The caller of the class will want to know what the parameters are, in 99% of the cases. At least so that he knows what's going on. So you must choose a parameter name that makes sense for the caller. This doesn't need to be identical to the name in the cpp. However this doesn't matter much, because I'm used to copy/past the function signatures from the .h to the .cpp in the first place. For me, programming in C++ implies this manual part.

您不需要字面上的名称匹配。指定接口的头文件有点像不完美的契约(不完美,因为它不包含前置条件和后置条件,除非你在注释中写下它们)和“调用者指南”。在99%的情况下,类的调用者将想知道参数是什么。至少这样他才知道发生了什么。因此,您必须选择对调用者有意义的参数名称。这不需要与cpp中的名称相同。然而,这并不重要,因为我习惯于将函数签名从.h复制/过去到.cpp。对我来说,用C ++编程意味着这个手册部分。

On the other hand, without names, it can often be confusing to determine what variables the parameters correspond to just by looking at the declaration.

另一方面,没有名称,通过查看声明来确定参数对应的变量通常会令人困惑。

That's the good hand.

那是好手。

#7

I suppose it depends on how descriptive your variable types are. If your method signature contains types used for multiple purposes, then it's useful:

我想这取决于你的变量类型的描述性。如果您的方法签名包含用于多种用途的类型,那么它很有用:

double calculateTax(int, string);

If the types are descriptive, then including the names is redundant.

如果类型是描述性的,则包含名称是多余的。

Money calculateTax(Order, State);

I'd prefer not to maintain the names in two files.

我不想将名称保存在两个文件中。

#8

Yes, it is not necessary to name the parameters in .h file. A header file is supposed to represent an interface, so it need not have unneeded details.

是的,没有必要在.h文件中命名参数。头文件应该代表一个接口,因此它不需要有不必要的细节。

HTH

#1