C++ Style Convention: Parameter Names within Class Declaration

Question

Hello.

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?

Answer 1

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

Answer 2

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.

Answer 3

Put the names in both - you will thank yourself for it later.

Answer 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.

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.

Answer 5

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

Answer 6

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.

Answer 7

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.

Answer 8

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.

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.

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.

Answer 9

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.