The me the best convention is Linux kernel coding style. I prefer slightly more verbose variable and function names on interpreted languages, to compensate the lack of static type checking, but calculateTaxOverTransfer() is probably too much.
Local variable names should be short, and to the point. If you have random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, if there is no chance of it being mis-understood. Similarly, "tmp" can be just about any type of variable that is used to hold a temporary value.
If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See chapter 6 (Functions).
The two examples given in support of short local variables names rely heavily on convention or prior knowledge. I don't think they're strong arguments for making short variable names.
Naming the integer counter "i" is convention learned in CS class (initially) that has become common usage. If you have nested for loops then j, k are often conventional for naming the next counter variables, though without an enclosing "i" they would look strange to most people.
Likewise, tmp draws on existing knowledge of /tmp as the location for temporary data on Unix machines.
Also in many early programming languages, variables could be only one or two letters. And in Fortran, the variables i, j, k, l, m, n were implicitly integers and others were real (that itself was as you noted, a carryover from mathematical formula conventions).
Relying on convention is a good thing, as long as your team (and the larger community for that language) is mature enough to have a strong set of relatively easily discoverable conventions.
Strongly agree. Conventions can produce code that is easier to read and to write. Certainly to the uninitiated, most of the formulas in a math or physics textbook look completely opaque. But by following conventions on meaning of symbols, they are precise and expressive and also easier to write.
I'm not saying convention is bad, I don't think that at all. I'm saying that the two examples here aren't good advocates for a general principle of short local variable names. The examples work only because people already know what they mean, due to the pre-existing conventions.
Longer names don't automatically make it easier to read. Quite the opposite.
In this particular example, probably the function should be eliminated completely. It's easier to read (value x tax / 100) than to hunt for the spec of calculateTaxOverTransfer() to see what it does. (I'm ignoring the weirdness of representing tax in % instead of a float; that's probably another opportunity for a refactor).
Even if there is reasonable business justification to have a specific function to calculate taxes over transfer (maybe multiple callers, the logic is more complex than shown, or there's expectation that the rule might change) something named calc_tax() doesn't reduce the least of your ability to understand what it does.
If there's business ambiguity (like many types of taxes), then yes, you may need to differentiate which tax you're calculating. Even then, I still prefer the C convention and having a single function that receives a parameter indicating the tax to calculate, like calc_tax( tax_type, amount, rate ).
But one could argue that it's a different use case altogether, and you're better off by refactoring your code, and encapsulating the logic in a class that understands different objects passed as parameters for a calc_tax method.
Local variable names should be short, and to the point. If you have random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, if there is no chance of it being mis-understood. Similarly, "tmp" can be just about any type of variable that is used to hold a temporary value.
If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See chapter 6 (Functions).
Source: Linux kernel coding style - https://www.kernel.org/doc/Documentation/CodingStyle