C++ 样式约定：类声明中的参数名称
我是一个相当新的 C++ 程序员，我想听听支持和反对类声明中命名参数的论点。
这是一个示例：
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_*/
与
#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; }
我无法决定。 一方面，我觉得在声明（.h）和定义（.cpp）中都命名变量是多余的。 特别是因为您必须担心更新两个位置的名称以使它们匹配。 另一方面，如果没有名称，仅通过查看声明来确定参数对应的变量通常会令人困惑。
所以你的想法是什么？
I'm a fairly new C++ programmer and I would like to hear the arguments for and against naming parameters within the class declaration.
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.
So, what are your thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
最好在声明中使用参数名称，并且使用好的参数名称。 这样，它们就可以作为函数文档。 否则，您将不得不在标头中编写额外的注释，并且使用好的参数/变量名称总是比使用注释更好。
例外：当一个函数由于外部原因必须具有一定的签名，但实际上并未使用参数时。 在这种情况下，您也不应该在实现中命名它们。
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.
将名字放在两个地方，清晰度是您在两个地方维护签名的任务所获得的奖励。
Put the names in both places, clarity is the reward you get for the task of maintaining the signatures in two places.
智能感知/自动完成/开发环境中的任何类似内容通常只会看到声明，并且只会将其显示为自动完成。 因此，如果您不在声明中声明名称，用户将不会在自动完成中看到它们，除非他们去阅读源代码。 这也许可以忍受，但不太方便。
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.
即使是多余的，我发现最好在两个地方都有参数名称。 这通常是因为更改参数名称通常会产生语义后果。 在标头中缺少它会搞砸文档（我倾向于在其中放置大多数注释，即 API 规范），并且在实现中缺少它会帮助我忘记为什么该特定参数具有如此奇怪的名称。
我唯一放弃参数名称的时候是当我必须实现第三方库回调并且我没有使用其中一个参数时。 即使那样我也会这样做：
这样我就能很好地了解签名。
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.
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:
so that I know the signature well.
如果您将代码作为库发布，并带有关联的 .h 文件，您的用户将永远不会看到定义，只能看到声明，从而给自己增加了 exztra 文档负担。
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.
您不需要名称与字面意思匹配。 指定接口的头文件的工作方式有点像不完美的契约（不完美是因为它不包含前置条件和后置条件，除非您将它们写在注释中）和“调用者指南”。 在 99% 的情况下，类的调用者会想知道参数是什么。 至少让他知道发生了什么事。 因此，您必须选择一个对调用者有意义的参数名称。 这不需要与 cpp 中的名称相同。 不过，这并不重要，因为我习惯首先将函数签名从 .h 复制/粘贴到 .cpp 。 对我来说，C++ 编程意味着这部分手册。
这就是好手。
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.
That's the good hand.
我想这取决于你的变量类型的描述性。 如果您的方法签名包含用于多种目的的类型，那么它很有用：
如果类型是描述性的，那么包含名称是多余的。
我不想将名称保留在两个文件中。
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:
If the types are descriptive, then including the names is redundant.
I'd prefer not to maintain the names in two files.
是的，不需要在.h 文件中命名参数。 头文件应该代表一个接口，因此它不需要包含不需要的细节。
华泰
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.
HTH