Agreed. The distinction between cliche and idiom is arbitrary. We have an idiom of using 'result' for many methods that return a value (e.g. derived getters, builders) making it clear that this thing we just introduced is what will ultimately be returned. As with any set of guidelines, apply common sense to suit your needs.

Agreed with you. Perhaps if you're using temp or tmp, something could be done better, but I see no harm in using the others. If you're counting things, a variable named "count" sound perfectly reasonable to me.

Even "temp" would be a standard name for the temporary variable used in a swap function.

https://en.wikipedia.org/wiki/Swap_(computer_science)#Using_...

Came here to say this. I bumped my head hard on this part of the text - the whole point of using a cliche is that it's immediately understandable. When I come across an incrementing loop that doesn't use a cliche variable like "count" or a function that doesn't return "return" it increases my mental tax. The nice thing about using a variable like "count" or "return" throughout your function is it's immediately intuitive what's going to happen with this variable.

Yeah this part is a bit ridiculous. A good reason to avoid "str" is because something more descriptive (and probably not much more verbose) would be helpful to see instead. "Because it's overused" is a silly reason, I would hope the author merely intends to criticize inappropriate overuse of these minimally-descriptive placeholder names.

When I'm mapping an array of line items with lodash, the predicate parameter is usually named "item" because it is short and perfectly adequate in context.

I find it funny the author considers `result` to be cliche, and renames it to `resultToReturn` which is obviously so much better.

From "The world's two worst variable names" [1]:

> I declare The World's Worst Variable Name to be:

    $data

> I declare The World's Second Worst Variable Name to be:

    $data2

I would lump in "value" with those two.

[1] http://archive.oreilly.com/pub/post/the_worlds_two_worst_var...

I have mixed feelings. For a return value, retval et al are completely appropriate. Same for count. Tmp/temp borrow meaning from whatever they are a temporary for. These are all fine.

But "value" is horrible. You really don't know what it is? You might as well name it "variable". "Str" is in the same boat, unless it's short for "tmpstr".

>You really don't know what it is?

What if I don't? Some of us program more abstract things than the others. For example I might want to write a function, that given a tree, and, well, a value, returns a tree where all nodes that have this value are removed. Doesn't matter that the tree in question will in practice be a tree of Flooblooators, I'd rather write reusable code that works for everything.

Ok, for those cases I have to agree with you. :)

If I'm iterating over a hash, it seems natural to use "k" and "v" or "key" and "value". Do other people use different names for these?

Yeah, there's lots of places where "value" is a well-accepted, clear, domain-specific language for a specific component of a construct, and thus using "value" is an excellent variable name.

(Similarly with data: lots of times, I've seen specs where a composite structure had a part called "data". Whether or not that is good naming in the spec, if I'm implementing the spec, using "data" for the element in the program corresponding to that part of the composite in the spec is clearly the exactly right thing to do.)

I typically keep it consistent, using either k,v or key,val (I like the symmetry of var letter length in a weird OCD kind of way).

Value isn't my favorite, but it says to me that it is data, and not a control variable.

I think that those are valid names in a good context. e.g. if you have a function like "substring", then you can name "str" as the parameter and "result" the variable where you accumulate the result. Any other more semantic name for "result" would be "substring", i.e. the name of the function itself.

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.

How about just "status" for the return code var name? It should be readily apparent that the var is "my" (the routine's) status [code].

Ok, 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.

I'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.

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

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

Yes, 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.

Yeah, the problem with outlawing "retval" in particular is that there's no good variable name in this situation:

  int sum(Collection<Integer> c)
  {
    int retval = 0;
    for(int i = 0; i < c.size(); i++){
        retval += c.get(i);
    }
    return retval;
  }

What the hell should I call retval? If I call it sum, that's redundant with the method name. Also, while it might work in Java, it would be more dangerous in a language like Ruby where the equivalent code:

  def sum(c)
    sum = 0
    c.each do |e| retval += e end
    sum
  end

would, due to lexical scoping, make it impossible to call the method recursively.

Call it "result":

- "val" in "retval" carries no meaning. Everything stored in a variable is a value.

- "ret" is an annoying abbreviation for "return" that makes it harder read.

- "return" focuses on an implementation detail—that the function produces its value using the language's "return" statement. It doesn't matter how the result is emitted, just that it is.

If a function is simple enough that the variable storing the result doesn't need a more specific name, "result" is a good default. You could call it "sum" here, but that shadows the function itself—a common problem for result variables—and doesn't really tell us anything we don't already know. We know we're inside a "sum" function.

"result" was also included in the list. I honestly don't see anything wrong with either.

I usually go for "result", but that was also on OP's list. I wish it was a convention to use "r" for retval variables.

Problem with that (for me) is that I use that for radius all the time, as in r * sin( a * t )

I'd call your method SumCollectionInteger and call your return value sum. This doesn't really work if you use function overloading though.

I would personally use the word "placeholders" rather then "cliches" and think most pros find them useful at times as they convey the proper temporary meaning of their use.

Yeah, I agree with you completely! Maybe not with val or value, but with everything else.

One of the best ways to calculate something is to build it up line by line. It makes the code really easy to follow. Also see my other comment about languages lacking "it", "that", etc. Result is sometimes a good substitute!

I will stop using these when smooth jazz stops punctuating turnarounds in bluesy minor grooves with a 7#9 chord.

I mostly agree. However, "tmp" and "temp" beg the question: "temp what?". But if you're using say node + express, and you're not using res and req - I'd have to question your sanity.

I think cliches are awesome.