I avoid systems that rely on complex and obscure abbreviations, like Hungarian notation. I always find this more confusing than helpful. Maybe if you got used to it you could read the prefixes quickly and immediately glean bunches of information, but even if you and I learned it that well, the chances are that other members of the team would not.
I particularly dislike Systems Hungarian where there is a prefix to indicate data type. Primitive data types are usually obvious from context: If I write "x=y+4", it's pretty obvious that x and y must be numbers, probably integers. Furthermore, an informative name should make the data type obvious: I expect "quantityOrdered" to be an integer and "customerFirstName" to be a String and not the other way around. If this is not true, the variable names are misleading and should be changed. Like, if "customerFirstName" is really a hash value of the customer name, then call it "customerFirstNameHash".
My one exception to this is when I have the same value with multiple data types, like if I'm reading an HTML form so I get a number in as a string and then convert it to an int. This almost always means a string and a "natural type", so I prefix the string variable with "s", like "sBirthDate" and "birthDate". I've had a few cases where I had a date as a long and also as a Date, in which case I've prefixed the long version with "l", like "lBirthDate" and "birthDate".
I have mixed feelings about Apps Hungarian where you use prefixes to indicate the semantic meaning of the data. While I don't use "real" Apps Hungarian myself, I often use some simple conventions like:
Indexes into an array or other "current number" are prefixed with "x". Counts of the number of something are prefixed with "k". A structure name is plural. The current element being worked is singular.
So for example, if I have an array of employees I'd write code like this:
Employee[] employees=buildEmployeeArray();
int kEmployee=employees.length;
for (int xEmployee=0; xEmployee<kEmployee; ++xEmployee)
{
Employee employee=employees[xEmployee];
... process ...
}
Of course this convention isn't limited to arrays, it works in any context where you have a structure with individual elements, counts of things, etc.
I often find myself having a key or other identifier that I'm looking for and the one I'm currently working, so I prefix these with "want" and "got" respectively, like "wantCustomerId" and "gotCustomerId".
Similarly, when processing through a list I often have a previous value and a current value of some identifier, so I prefix these with "prev" and "curr", like "prevCustomerId" and "currCustomerId".
That's about the only common cases I can think of.
I have a few "never ever do this" rules.
DO NOT use generic names like "x" or "num". There are only two exceptions to this: (a) Variables used for an extremely short span of code, like an index in a 3-line loop. (b) Generic functions. Like, if you have a function that adds a number of days to a date, sure, you can call the variable "date" because it could be the date of anything. I used to work with a guy who regularly named all his integer variables n1, n2, etc, and all his string variables s1, s2, etc. Reading his code was a nightmare, full of lines like "n4=(n5-n9)*n3". I finally concluded that the only way to maintain his programs was to first go through and figure out what all the variables were and rename them to something meaningful.
DO NOT re-use variables for different data. If you have a function that, say, gets the sale amount and does some processing on it, then gets the tax amount and does some processing, then gets the payment amount and does some processing, create three fields, e.g. "saleAmount", "taxAmount", and "payAmount". Don't use a single variable "amount" for all three. Modern computers have enough memory that creating a few extra variables is not going to use it up. The gain in readability far exceeds the trivial value of the "saved memory".
DO NOT use inconsistent abbreviations. If you want to abbreviate quantity as "qty", fine, I can probably figure that out. But don't use "saleQty" over here and "stockQnty" over there and "orderQuant" some place else. Pick one abbreviation and stick with it.]
If two variables are similar, DO NOT distinguish them with numbers or deliberate mis-spellings. If you have, say, a sale total and a refund total, DO NOT call them "total1" and "total2", or worse, "total" and "totl". I have seen this done so many times it makes me want to throw up. Give them names that give us a clue how they are different, like "saleTotal" and "refundTotal".