I like the rule of thumb that an identifier in code should usually be longer and more specific as scope increases. The main exception is that if your problem do

I like the rule of thumb that an identifier in code should usually be longer and more specific as scope increases. The main exception is that if your problem domain has well-established terminology or notation for some concept, reflecting that as closely as possible in the code is often best. So, I personally have no problem with someone using short identifiers and concise notation if it’s either used very locally or idiomatic. For example, suppose we have a function whose job is to calculate two vectors of weights and do something unless they are equal but opposite. Personally, I would rather read something like v = someCalculation() w = someOtherCalculation() if (v ≠ -w) { doSomething() } where we use short names for the local variables and vector-aware unequality and negation operators, than read something like weights1 = someCalculation() weights2 = someOtherCalculation() if (not(vector.equals(weights1, vector.negate(weights2)))) { doSomething() } The longer but still arbitrary names for the vectors add no value here and the longhand function names for manipulating them are horrible compared to the short and immediately recognisable vector notation. In general, I think there could be advantages to using a broader but still selective symbol set for coding, as long as we also had good tool and font support to type and display all of the required symbols. I would be hesitant about including Greek letters in that symbol set, but that’s because several letters in the Greek alphabet look similar to other common letters or symbols, not because I think calling a value ω_0 is a bad idea if that’s how practitioners in the field would all write it mathematically.