Optimize for Readability.

Your audience is a human reader, NOT the compiler.

The code only has to be written once. If it is not a one time throwaway, then during its lifetime, the code will have to be read and comprehended many times. Ideally it should be easier, not harder, to comprehend a routine someone else wrote. Like when you read code in a book or article. Write your code as if you are explaining it to someone intelligent.

See Y2K.

I wrote some core library/framework code in 1983. We expected to have rewritten that long before Y2K. We had plans for grand architectures beyond the code we were developing in 1983.

In 1997 we had to retrofit that code for Y2K. Reminiscing, we were all very surprised that customers were still using that code in the obsolete version of our system, which itself had years ago been ported to a p-System emulator that ran on DOS, and had other things done that kept extending its useful life.

I would also point out that programmers in a completely different world (COBOL, mainframes) had Y2K issues with code written in the 1970’s, predating microprocessors.

Your code may even outlive you. A StringUtils library, or JPEG decompression routine, for example, may live far longer than you would anticipate.

Except where short or single letter ones make sense. Be consistent in your use of names. Create a glossary if necessary. Think about identifier names. Use words that are more specific rather than general.