I disagree, depending on the context. Data is an acceptable variable name to refer to binary blobs that don't have a type, eg, this is roughly the low level class that holds data that I'm streaming in (files may either be in a pack file or downloaded while the game is played):
class packFile {
var name:String;
var location:String;
var downloadPriority:Int;
var data:Array<Byte>;
}
There may be a better name than data, but I can't think of one off the top of my head, and it's certainly not a bad one.
Another example: in my work group, "data" specifically means "measurements made in the real world." Numbers generated by a computer simulation don't qualify. So in our code, "data" could be a perfectly meaningful variable name.
Personally, the worst variable name I've ever seen was "C". This was a vector of concentrations. Unfortunately, the language was Fortran-77-- where a "C" in column 1 indicates a comment line.
Wow, I think you actually may have won. That's a terrible name for a variable given the context. You would probably have nightmares for years after maintaining a project like that :)
When you use i and j as loop indices, everybody knows what you're talking about. It's idiomatic. How is that bad variable naming if its the clearest thing for everyone?
Nobody's suggesting that i and j be used for anything other than loop counters: integers. In fact they come from FORTRAN, where a variable starting with a letter [i-n] was an integer, whereas variables starting with other letters were floats.
Personally, I much prefer the certainty of the current situation to the relative uncertainty of a free-for-all. That and for (counter = 0; counter < N; counter++) seems very longwinded.
> Nobody's suggesting that i and j be used for anything other than loop counters: integers
You're right, I missed the 'indices' part of your original comment. Unfortunately I've worked at a couple of places where they're used in every for loop.
Maybe this is just a personal thing, but it always struck me as odd that the recommended variable names for loop counters are the two letters that look most similar to a semicolon. I tend to use x and y.
A really bad variable name should confuse the reader as much as possible. If I remember my compiler design classes correctly Pascal (?) allows you to name variables the same as language constructs. That means you can write something like
FOR FOR = WHILE WHILE WHILE = FOR
Now THAT'S bad variable names. :)
Isn't there an example like this in the Dragon Book?
Best case scenario: you named that something well so all I have to do in your great big for loop is scroll up, work out what you meant, and apply that to the code I care about, being mildly annoyed.
Worst case scenario: the something is also badly named and I have to open up a debugger and set a trace to work out whether the iterable is people, channels, cows, or dinosaurs.
Yes I know this is common behaviour. So are many other bad things.
I didn't say it can't be figured out at all - please don't put works into my mouth.
Code is read much more than it's written and should be created for maximum comprehension. A simple one-line method call should be understandable without having to read any surrounding line.
>Best case scenario: ... all I have to do in your great big for loop is scroll up...
Once you have to scroll up, you are toast. I mean within a function, not within a loop.
There is a rule of thumb of how many things can the mind process at the same time: It is 7 plus-minus 2. You can treat the loop as one element in the function context and analyze the loop context at a different stack frame inside your head.
While working in a loop, you have to think about the list, the index and the element, so you are down to 4 more things you can do before "running out of memory". I think that's why the "for each" loop has been successful across many languages. I also think that that's why "i" is preferred over "index"; it is a known idiom that helps you think about the "i-th element" and saves one slot in your brain.
>Worst case scenario: the something is also badly named and I have to open up a debugger and set a trace to work out whether the iterable is people, channels, cows, or dinosaurs.
Eventually, anyone who has been around for a while inherits some abomination like that. It is not funny. However, no amount of coding standards prevent morons for doing their thing. I would not sacrifice an useful and well known artifact for the sake of idiot-proofing.
Oh thank god it's not the stuff I use. My code is so bad that every time I declare a variable a fairy dies. At least there's something I'm not doing wrong.
$data is a perfectly fine variable name, if it's used in the correct context. Such as pulling a result set out of a database. In that case, it's exactly like using i in a for loop.
Anything postfixed with 2 is more shady, I agree, but the absolute worst variable names are the ones that say they are something they're not - such as a column named "tablename_key" - which is actually a foreign key, but not in "tablename".
Often when I read something from a file or socket, prior to parsing, it's called data. Same goes for the information to be inserted into a template, or intermediate structures when transforming datasets or documents without knowing their type.
Data is the variable name you use when you don't know, or can't specify, what you're dealing with.
I think that names that are wrong are worse, like something called $xmldata which doesn't contain data in xml format, or $price_in_cents which actually contains $price_in_dollars but nobody has bothered to change it.
I'm guilty of using tmp quite a lot. On my defense though, it's usually just that, temporary: I end up refactoring it down the road (most of the times)!
I completely agree. I don't understand why foo and bar are so prevalent. Not only are you trying to describe something abstract (computer code), you are now adding another layer of human language abstraction on top of it. In many cases why not use a simple scenario people can relate to rather than foo and bar.
foo and bar are the Lorem Ipsum of code. They let you look at the flow without getting caught up in certain details. You look at 'for', 'while', 'if', and other operators more closely when the identifiers are place-holders.
class packFile { var name:String; var location:String; var downloadPriority:Int; var data:Array<Byte>; }
There may be a better name than data, but I can't think of one off the top of my head, and it's certainly not a bad one.