I've seen code of the form:

void doSomething(int) {
    ...
}

doSomething(3);

No variable name for the parameter is specified. Creating a small test program, if I step into the doSomething function, I see there is a local variable called __formal, which has the value I passed into the function. I'm confused as to why one would do this? I can access the parameter using the __formal variable. You can also specify multiple parameters, such as:

void doSomething(int, float) {
    ...
}

doSomething(3, 17.0);

The debugger says there are two local variables called __formal, but I don't see how I can access the 2nd parameter; __formal gives me the first parameter. I am also looking at production level code where they do this, and they never access a __formal parameter in the body of the function. Why force the caller of the function to pass in the parameter when it is never used? edit: Language = C++, compiler = VS 2003

If a base class has a pure virtual and the child doesn't make use of the passed in arguments then not declaring avariable name will avoid compiler warnings (unused argument).

At a guess __formal is created by your compiler for debugging purposes

wait!

I intentionally leave unused parameters nameless like that, because in level 4 compiler options, it otherwise gives warnings for defining parameters that are not used.

In fact, all my function definitions always have the parameter type only.

I.e.

class someClass{	...	virtual const int JumpToNextEmail(const int, const TCHAR *);	virtual const int SkipWhiteSpace(const int);	...}

Yeah, quite common to leave only the argument type in the declaration.

Summary and clarification:

- Assuming C++ here.

- Names starting with a double underscore are reserved for the implementation; thus, anything you see named "__formal" is non-standard, and you can't just write code that accesses "__formal" and have it be portable (as evidenced by the fact that there's a name collision when there's more than one such parameter). The debugger for your IDE is generating the name, so that you can see the value of the parameter even though your code can't (reliably) access it. This could be useful in that, if the value ever changes, you know you have an array bounds error or a corrupt pointer somewhere (because you wouldn't otherwise be able to write to that area of memory).

- In *declarations*, it is common to omit the names, because they aren't necessary (the parameter name is NOT part of the function signature - as evidenced by the fact that you can't overload on it - and there's no code locally that needs to use the parameter, so there's no need to name it), so it saves typing (as well as updating work, if you decide that you want to rename the parameters in the implementation). However, some prefer to keep the names (myself included) for documentation purposes (you can read a header file or class body and see what the parameters are *for* via their names).

- In *definitions*, omitting the name denies you access to the parameter. This can be useful: sometimes you have to accept a parameter that you don't need in order to conform to some interface where function pointers, operator() overloads, etc. are involved. Omitting the name signals to the compiler "I have to accept this parameter but I will not use it", which will cause it to suppress warnings that tell you "hey, you accept this parameter but don't use it anywhere; I suspect you forgot something".