9 ms·
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 y
by WiseWeasel 15y ago
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.
- eridius 15y agoEven 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]; }
- WiseWeasel 15y agoThat'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.