I personally prefer short and cryptic names for things that are used very often, but don't shoot the messenger. My main point are the trade-offs. Some of that

I personally prefer short and cryptic names for things that are used very often, but don't shoot the messenger. My main point are the trade-offs. Some of that is from mathematics, for example (random code from the Internet): reverse2 xs = go [] xs where go ys [] = ys go ys (x:xs) = go (x:ys) xs In general, more abstract you get, the less important it is to devise long names, because things are going to be abstract anyway. Often, all you can tell about the object is already encoded in the type system. Even in current practice, people prefer "log.info(..)" to "centralizedLoggingSystem.informationalMessage(..)". They prefer "Exception e" to "Exception unexpectedlyFailedToWriteAccountingFileException". We also prefer to write "a * b" instead of "a.multiplyBy(b)". Sometimes simply the global consistency trumps the local context.