I have found that when I start reaching for long variable names it's because there is a design problem. Ideally the use of the variable should be obvious from the context. As you find yourself adding more and more context to the name, you should realise that it's because you lack context in your design.
Deriving meaning from the context requires understanding the context. That's fine for the original author or the refactoring dev, but the troubleshooter swooping in to fix that problem that's obvious in the UI needs to be able to understand the variable names with as little context as possible. "Well, if you'd just spent a few hours to truly grok the intent of the code, ..." is not an acceptable answer when it's possible to make the solution transparent as easily as making more descriptive names.
Descriptive names are great when a symbol is used in many scattered places. Context is okay when the definition is right in front of you. When a function is short enough, context for a parameter should mean reading the function's documentation written immediately above it. Or if the scope of a local variable is three lines, its initializer often explains what it is, and it's right there.
Very well put. I wish everybody could get this concept. With this kind of attitude, you are going to write code that is easier to read, is easier to update and debug, and has fewer bugs in the first place.
Code with long identifiers is harder to read, not easier to read. It's harder to see the flow of data and the flow of control, because there is invariably a soup of common prefixes throughout, performing the contextualization.
If you're in the middle of the spreadsheet reader, it should be self-evident that 'row' means a row in the spreadsheet; if you're in the middle of the database insertion logic, it should be self-evident that 'row' means a row in the database.
I use 'row' as a variable name quite a lot, especially in loopy situations where it's obvious. The more problematic times are when you have things like a source and a destination row dealing with, say, cows, and you call one of them 'row' and the other one 'cow\_row', and in different places pick which kind of row is which at apparent random.
Or the situation with the file names, as someone else mentioned at more length.
