Then you're thinking in math and also writing in math, so you're getting the second bit wrong. You need to write in code, and code should be optimized for readability.
Actually, I think a good, justly polymorphic function should probably have a word of a reasonable length and parameters that are called `a`, `x`, `f`, since the parameters convey almost no information. If they have any greater length, it's just a restatement of the known information about the type.
The more unique information a name conveys, the less information the types convey and the bigger a chance you have of bugs or coding yourself into a hole.
But also, if you've called it `x` hopefully there's only one thing it can be and its scope is just one or two lines so you've written a single unit. If there's anything else `x` could be, then you've got a problem - your unit is too much.
Not every piece of code should be written this way, but your vocabulary should be built up of pieces like this.
I don't. One of the things I like most about eslint is the id-length rule - https://eslint.org/docs/rules/id-length
I think there are a lot of advantages to abiding by styling conventions and using linters to set a baseline, but there are always exceptions to the rule.
Note that the id-length rule also allows you to limit the maximum length of a variable name. This is why.
`
/* product of luminance and dot product of surface normal and light direction divided by scattering constant */
const prod = ...
`