E=m*c^2 or
objectEnergyInJoule = massOfObjectInKilograms * speedOfLightInVacuum^2 ? a = b/c
or numApples = numBananas/apple BananaConversionRateI would rather give a function the descriptive name in such a way that the parameters can then be given trivial, mnemonic names.
Strawmannish example:
incrementAccountBalance(a, n)
{
...
}
The descriptive function name gives away what a and n are, so it is unhelpful to make this: incrementAccountBalance(account, amountToIncrementBy)
Reasonable middle ground: incrementAccountBalance(acct, delta)Further, non-descriptive naming often assumes that the programmer reading and modifying the code has domain-specific knowledge. That might be true of mid level or senior engineers have have been with a particular company for years, but the new grad coming into a financial services company (a field he has no training or familiarity with) will have no idea what "a" or "b" means. I was in that position, and the descriptive naming absolutely would have helped me to learn and become productive with the codebase faster.
I'd say that your reasonable middle ground would be the best practice.
Not if you use Unicode (and Chinese language).
Also 80 columns is near impossible to adhere to for more verbose language.