Meaningful names for variables, methods, and classes go a long way to making uncommented code possible. However, meaning is not conveyed simply by length.
Consider this snippet (a real example, with the class name changed)[1]. It’s just a variable declaration in a method that’s only a few lines long, but it conveys the point:
DamnThatIsAVeryLongClassName damnThatIsAVeryLongClassName = new DamnThatIsAVeryLongClassName();
This manages to tell me the same thing three times: it’s a very long class name (with emphasis!). It tells me precisely what the variable is, but gives no hint to what it is going to be used for.
When you keep method lengths short (I advocate under 25 lines, to ensure that the entire method is visible on screen, including any explanatory comment for the method), you shouldn’t have to worry about preserving “type” information in a variable name. The reader shouldn’t have had time to forget it. Convey “what”, “which”, and “why” information instead.
[1] Believe it or not, it’s actually a longer class name in the original.
Share this:
Software is too expensive to build cheaply.... 
So size isn’t everything.
A lot of people still live in terror of conventions like:
lpstrWndTitle and lphwndMain and so on…
Perhaps longer classnames are more useful in cases like:
SomeInterface something = new WhizBangThingThatDoesItThisWayImpl();
So the really long name is only really visible when it counts (when you are injecting the specific implementation of choice).
Or just use better names.
I don’t actually mind long class names, or even long variable names (and, to be honest, the class name in the example wasn’t bad). What I’m commenting on is that length doesn’t automatically convey information.
I’m also opposed to redundant information that isn’t required due to the surrounding context. For example, a method signature like this:
public void removeItem(Item itemToRemove);
has redundancy. I know I’m removing an Item (I’m passing an Item in), so why not just call the method remove(Item itemToRemove)? And it’s obvious that the parameter is the item being removed, so why not just have make it remove(Item item) or remove(Item theItem)?