I don't mind long names, but I think I went overboard. Maybe there's another principle here:
a name should be as long as necessary, but no longer.
Or how about:
a name should be as short as possible, but no shorter.
-- Kiel Hodges ;-)
Variable name size should be proportional to scope -- Use names like i, j, k as counters in small loops, item_index in a larger context, gSysObjects_MAXITEMS as a global constant. The name should minimize what it requires of the programmer. A set of cumbersome names instead of i, j, k in a small set of nested loops is harder to read and understand. A small name like 'index' in a large scope becomes difficult to identify. The more mental effort something requires, the more likely it is to lead to mistakes. Working professional code does not and should not look like example code. There is research to show that programmer errors are proportional to the number of symbols in a statement. The more conventional or frequently used a name, the shorter it can and should be. The more obscure it is, the longer it should be.
-- Bob Trower
Use ii, jj, kk instead of i, j, k. Much easier to search for/highlight/etc.
I thought the Einstein Principle Of Software Design is Everything Is Relative.
I would think that since the name suggests it's about Software Design, it would apply to choosing an implementation or algorithm to do something. Such as picking one over another simply because it was short and easy to understand, but only worked in a very limited set of cases or specific circumstances. For example, I recently saw something proposed one a Q & A site that consisted of only one or two lines of code, however it only worked properly when there were no local variables also in the function.
See original on c2.com 