Item — HN Reader

For every rule an exception - data is a perfectly fine name for the scenario where we don't know what data the variable represents. For example in a logging framework that has to loop over the contents of a collection and dump it to the console then data or entry or something similarly vague would be a perfectly reasonable variable name.

Then data2 might be a reasonable name in a unit test that checks to see if a function can handle the traditional "1, 2, many" categories of failure.

Which is not to say that data and data2 are not, often, horrible names. But the circumstances dictate (or excuse) all.

2 comments

You could name it after the source of the data. The point the author was making is it makes your code much more readable when you see the variable turn up and you don't need to go back and see where it comes from to determine what it is (ie you come accross a 'data.parameter < constant' condition or some such). Even calling it log-data would be an improvement, as its source is immediately obvious from the name.

Even the source is not always obvious. Cocoa has a class called NSData, which is a container for arbitrary binary data (e.g. it basically holds a char* , a length, and a bunch of methods for looking at this stuff). If I write a function that needs to operate on an NSData instance, then I'm perfectly justified in calling the variable 'data'. For example,

  NSData *calculateHash(NSData *data) {
      char result[CC_SHA1_DIGEST_LENGTH];
      CC_SHA1([data bytes], [data length], result);
      return [NSData dataWithBytes:result length:CC_SHA1_DIGEST_LENGTH];
  }

That's a good point. If in the scope of the variable, you're only concerned with calculating its hash (or some similar function that is qualitatively indifferent to it), and not testing or parsing it or making any specific use out of it, then 'data' makes sense (though I'm guessing 'file' is arguably a better descriptor of the data in this example, if indeed that's what you're hoping to find in NSData, I get your point, and 'foo' might do just as well). That has to be a fairly unusual case, though.

'datum' often is a more appropriate name. 'data' is ambiguous w.r.t singular/plural.

However, I prefer 'item' and 'items', as that completely evades any possible confusion. Especially useful when iterating over generic containers. Compare:

  Foreac

Oops, hit the "reply" button by accident when trying to dismiss a spelling correction on the iPad, and I do not know how to edit, due to my anti-procrastination setting. Intended was to compare:

  Foreach item in items

With

  Foreach datum in data

I also use itemss for a container of containers:

  Foreach items in itemss
    Foreach item in items

Of course, if the code is less generic, different names are more appropriate:

  Foreach row in matrix
    Foreach cell in row

For small scoped loops, I usually just abbreviate to the first letter. I'm not sure how others feel about this, but I think it's perfectly legible:

  for i in items:
    i += 1

  for r in rows:
    for c in columns:
      matrix[r][c] *= 2