function prototype with named argument(s)

[RobiBue]

If I write a function prototype, i.e.:
int foo(int);
the function returns an integer and accepts an integer, which is clear.

now, my question:
is it 'OK' to define the function prototype with the name of the passing argument, i.e.:
int foo(int bar);
to visualize the passing arguments, or is this a bad practice?

A better example:

double amort(double principal, double interest, int months);
//                  ?????????         ????????      ??????
//                  good              or            bad?
int main()
{
    double prin, inter;
    int mon;
    cout << "Principal: "; cin >> prin;
    cout << "Interest : "; cin >> inter;
    cout << "Months   : "; cin >> mon;
    cout << "Payment  : $" << amort(prin, inter, mon);
    return 0;
}

double amort(double principal, double interest, int months)
{
    double pmt=0.0;
    // calculation of amortization
    return pmt;
}

This way, someone that modifies the program doesn't have to look for the function itself but can already see from the prototype which arguments go where.
Again, is this good or bad practice, and what is standard practice?

Thanks for your inputs.

[diedrexler]

Standard practice? Every development team has its own set of guidelines regarding docs. However from experience, the header files just contain stuff like std::ostream& printData(std::ostream&) and we just refer to the docs when looking to make adjustments within the code itself.

[Disch]

I tend to name them when it's not obvious what the parameters represent. When it's obvious I often leave them unnamed.

In the case of your amort() function, naming them is good because the order of the params isn't obvious.

However if you have a function like this:
void printnumber(int numbertoprint);

Naming that is kind of silly because it's clear what the parameter is. But I suppose it doesn't hurt.

[sohguanh]

I believe if you spend close to 80% of your time maintaining other developer's code, you really hope they name all their arguments be it already obvious or not obvious. This can drastically cut down your time understanding, trouble-shooting, doing bug fixing and enhancement on those code. Trust me I been there and I know the pain.

[Mathhead200]

It's not "bad practice". However just don't change what they really mean in the definition because the compiler optimizes the names out, and it could get really confusion.

i.e.

double amort(double principal, double interest, int months);
... //"files" go by

//Whoops!           !!!!!!!!         !!!!!!!!!
double amort(double interest, double principal, int months)
{
    double pmt=0.0;
    // calculation of amortization
    return pmt;
}