>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?
Re:A Guide to Naming Variables
by dragonwriter on Friday May 13, 2016 @12:36PM
(#11691384)
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.)
Re:A Guide to Naming Variables
by bobwaycott on Friday May 13, 2016 @01:19PM
(#11691709)
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).
Re:A Guide to Naming Variables
by mixmastamyk on Friday May 13, 2016 @12:16PM
(#11691236)
Value isn't my favorite, but it says to me that it is data, and not a control variable.
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".