3 ms·
I guess what he's getting at here is that these variable names don't convey what the variable holds. Let's say you're writing C and you want to return status i
by Niksko 10y ago
I guess what he's getting at here is that these variable names don't convey what the variable holds.
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.
- Roboprog 10y agoHow about just "status" for the return code var name? It should be readily apparent that the var is "my" (the routine's) status [code].
- Niksko 10y agoOk, the 'function' part is not useful. And perhaps C was a bad example. 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.
- Roboprog 10y agoI'm OK with the "one word" parameter / return value names, in part, I guess, because I'm also a big proponent of a "pro forma" comment banner for every routine. For simple things, the comment can be a one-liner ("Return thing X"), but otherwise, explain each param and the return value. Now, if the internal variables require a "data dictionary" level set of comments, that's another matter. Something is (usually) wrong in that case.
- mixmastamyk 10y agoYes, sometimes a more specific name makes sense, which is why I allowed for it above. But, sometimes I use generic names on purpose, so that I can factor the code into something general.
- snarfy 10y agoI find this less useful than using retval. I might have a half dozen variables like parserStatusCode in my function, but there is only one retval. What you return is defined by the function definition. It's extra boilerplate to call your variable parserStatusCode when then function is called getParserStatusCode() returning a type of ParserStatusCode.
- BurningFrog 10y agoWhat the function is returning should be clear from it's name. 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.