A good name is like a good car. Is a race car a better car than a truck? Lot of trade-offs to make.
You want names to be short, so you easily write and read them. Especially if you use them a lot, it's useful to use abbreviations, like x, e, i, z.
You also want names to be easy to understood, therefore, longer than few letters. So, "count" instead of "cnt" or "c", in short, no abbreviations.
You want names not to clash. So every name should be a unique 64-character long identifier, as far as distant from anything else as possible. However, they should also be optimized for the tree search when using completion.
You want names to describe similar things with similar names. In particular, my pet peeve, how to name objects that are "essentially the same thing" but only different structure so I could better manipulate them, like converting list of tuples to a dictionary? From purely domain point of view, they should not even have different types! And did you know that every Monad is an Applicative?
Should the name reflect the result only or also the path that was taken to get to it - "customerList" or "customerListFiltered"? Or perhaps just "list", because the function is not specific to customers. It's local context versus global consistency.
There are minor problems as well. Underscore_case looks ugly, dash-case is mostly not supported, camelCase is just weird when you want to have anotherCamel (now strangely upper-cased), and CapitalCase looks ugly with acronyms. And should we put adjectives in front or at the back? And why are the elements of EMarble called RED, GREEN and BLUE?
You want names to be short, so you easily write and read them. Especially if you use them a lot, it's useful to use abbreviations, like x, e, i, z.
You also want names to be easy to understood, therefore, longer than few letters. So, "count" instead of "cnt" or "c", in short, no abbreviations.
You want names not to clash. So every name should be a unique 64-character long identifier, as far as distant from anything else as possible. However, they should also be optimized for the tree search when using completion.
You want names to describe similar things with similar names. In particular, my pet peeve, how to name objects that are "essentially the same thing" but only different structure so I could better manipulate them, like converting list of tuples to a dictionary? From purely domain point of view, they should not even have different types! And did you know that every Monad is an Applicative?
Should the name reflect the result only or also the path that was taken to get to it - "customerList" or "customerListFiltered"? Or perhaps just "list", because the function is not specific to customers. It's local context versus global consistency.
There are minor problems as well. Underscore_case looks ugly, dash-case is mostly not supported, camelCase is just weird when you want to have anotherCamel (now strangely upper-cased), and CapitalCase looks ugly with acronyms. And should we put adjectives in front or at the back? And why are the elements of EMarble called RED, GREEN and BLUE?