Names matter

Names matter in many domains and many ways. People like to be referred to by their name, not a number, or some generic term like "mate" or "buddy". Our name identifies who we are as an individual. In the "olden days" our surnames (at least in the Western world) were often derived from what we did as a profession (e.g. Smith, Baker, etc) . It's not that different in the coding world, names identify the purpose of an entity, what it does, what it's for, why it exists. At least they should.

Many developers do not take the time to think about what their interface, class or method is and will be for, and hence name it appropriately. A generic name like "MyClass" simply means we (any one else in world other than the author) have to read the documentation (if there is any) or the code itself, just to get a feel for what it does. And using uncommon terms and abbreviations doesn't help either. All this wastes time, everyone's time, even the author's himself after some time has gone by.

Providing a name that matches the purpose is mantra of Java, and it should be for all coding. In fact it can be applied much wider than just Java code, what about HTML pages, and documents (yes .xls and .docs), and don't forget packages and directories. I'm not going to provide specific details on naming conventions or formats here, they are included in most standards and guidelines out there.

It is also important to re-name (or refactor) entities when their meaning changes. Or provide a new one (perhaps a sub or super-class of the existing one) with a name that fits better for a new variation. In Java you can even keep the old name as a unchanged sub-class of the new name, and "deprecate" that old class.