Let's say it's Python now, and for some reason I'm still returning 0, -1 or -2. Then 'statusCode' would be a good name for the variable I guess. The code part indicates that it's a codified version of the status. The smarter way might be to just return a status object or something, in which case perhaps 'statusObject' is better? Not sure.
I guess one thing I took away from the article is that it would be nice to be able to encode _how_ the data is being returned in the name of the return value. This saves me going and finding when the variable was created to get its type, or when the variable was assigned to.
Now, if the internal variables require a "data dictionary" level set of comments, that's another matter. Something is (usually) wrong in that case.
Repeating that in the return value variable is then redundant.
I like naming my result variables `result`. It makes it clear when you first see it what it's for, without having to read the function to the end.
But, sometimes I use generic names on purpose, so that I can factor the code into something general.
Let's say you're writing C and you want to return status information from processes as integers. Instead of:
> return retVal;
where retVal could be 0, -1 or -2 to indicate success or failure of the function, how about:
> return functionStatusCode;
? Or be even more specific (let's say the function tried to parse some text) with parserStatusCode.
All of those are more helpful than retval, because they give you some sort of idea as to what you're returning. You'r enot returning how many values were parsed, or some sort of information about what you parsed, you're returning the status of the parsing function.
The meaning of those values is probably a little harder to encode in the variable names (especially if there are many such values), but that's what the comments are for.