C ++ Style Convention: Parameter names in class declaration

Question

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

---

Here is 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_*/ 

against.

 #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 can’t decide. On the one hand, I believe that it is redundant to name variables both in the declaration (.h) and in the definition (.cpp). Especially since you need to worry about updating the names in both places to match each other. On the other hand, without names it is often difficult to determine which variables match the parameters simply by looking at the declaration.

So what do you think?

Answer 1

It is much better to use parameter names in the declaration and use good parameter names. Thus, they serve as functional 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 also not specify them in the implementation.

Answer 2

Put the names in both places, clarity is the reward you get for completing the signature job in two places.

Answer 3

Intellisense / autocomplete / something similar in the development environment usually sees only the declaration and will only show it as autocomplete. Therefore, if you do not declare the names in the ad, users will not see them in the autocomplete unless they go and read the source. It is possibly bearable, but not very convenient.

Answer 4

Even if redundant, I find it better to have parameter names in both places. This usually happens because changing a parameter name often has semantic consequences. The absence of it in the header helps to spoil the documentation (in which I, as a rule, put most of the comments, i.e. API Specifications) and skipping it in the implementation, helps me forget why this particular parameter has such an odd name.

The only time I predetermine a parameter name is when I need to implement a callback to a third-party library and I do not use one of the parameters. Even then I would do:

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

so that I know the signature well.

Answer 5

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

Answer 6

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

You don't need names to match literally. The header file that indicates the interface works a little like an imperfect contract (imperfect because it does not contain preconditions and postconditions if you do not write them in the comments) and the "caller’s guide". The calling class will want to know what parameters are in 99% of cases. At least so that he knows what is happening. Therefore, you must choose a parameter name that makes sense to the caller. This does not have to match the name in cpp. However, this does not really matter, because I'm used to copying / skipping function signatures from .h to .cpp in the first place. For me, C ++ programming implies this part of the tutorial.

On the other hand, without names, it can often be confusing which variable parameters correspond only to the look at the declaration.

This is a good hand.

Answer 7

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

 double calculateTax(int, string); 

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

 Money calculateTax(Order, State); 

I would prefer not to support names in two files.

Answer 8

Yes, there is no need to specify parameters in the .h file. The header file must be an interface, so it does not need unnecessary details.

NTN