Now imagine that you're not looking at a famous equation and you tell me which one you would rather have to sus out the intention of.

    a = b/c

or

    numApples = numBananas/apple BananaConversionRate

The first one, no question about it.

Yes. We would want the descriptive names for identifiers which have broad scope, but short names for the local variables that work with them.

I 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)

With incrementAccountBalance(a, n), it's impossible to tell exactly what each argument is from the function signature alone. Of course I could assume that a = account and n = amount to increment by, but that's nothing more than an assumption, which only invites inevitable bugs. Alternatively I could look at the function body, and try to figure out what's going on, but that's time wasted that could be spent more productively.

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.

Opposite of my choice of which I also have no question.