I guess it depends on how concrete the code is. For very general things there just are no good names. I see the point in calling a variable anualSalary, say, but in a function for reversing a list is elementOfList really better than element or than x (which would be my preference)?

This, by the way, is probably the main reason math uses single letters for names (with some rules of thumb that hint at the type, like n for an integer, X for a scheme, calligraphic F for a sheaf, etc.).

I've personally written code that was immensely difficult to read. Branchless stuff with single letter variables. Even though I commented it thoroughly, its ridiculously difficult to read and modify.

This was a good lesson for me, I won't do that again and I'm far more verbose now.

My thinking is that maybe math should learn from things like that as well, perhaps expanding equations and being more verbose within the equation instead of an explanation next to it would make maths more accessible to a broader audience.

After developing equations through 100 lines and few pages or blackboards, you’ll see that dropping letters is inevitable.

You shouldn’t really read the equations before understanding what they are about.

They are usually written down to get rid of ambiguities of the natural language.

Source code isn't ambiguous either, and tends to get way longer than a hundred lines or a few pages.

It’s not a single equation though where you’d need to rewrite the same variables 100 times.

Another perspective: Working memory for equations becomes tricky once they span lots of lines or multiple pages and long variable names make this worse.

Same reason one often sees I1 + I2+I3+I4 in estimates. For the moment you actively don't want the mental overload of all the details. You just want to know that there are four terms to be discussed, now forget about all others and let us start looking at the first one.

Similarly long notation/names just do not work well on blackboards/whiteboards.