I have serious OCD about naming. Sometimes I just sit and think (or talk out loud..) about what a good/better name for whatever is.
And I really mean whatever- package names, class names, method names, variable names, project names, component names, build tasks.. Along with naming OCD, I also have convention OCD such as: singular or plural names (for database tables, packages), camelCase vs snake_case, space vs tab, 2 vs 4 vs 8 space indentation.
However, I’ve got a few preferences, only they sometimes are in conflict and I haven’t decided on how much weight each has (need to figure it out still). They are:
- when trying to keep things ordered, put them in alphabetic order (ignores, properties, imports, fields, setters/getters)
- when trying to find a name, given two real synonyms, use the shorter of the two (but it has to convey the same meaning)
- avoid abbreviations and acronyms (this is in conflict with the previous preference..)
- name it using English
For that last reason I’ll give an example. I have a project that uses assignments. Without going into detail, I sometimes deal with lists of assignments, other times maps of assignments. I, therefore, have started using the convention of writing variables such as assignmentsMap instead of assignmentMap, because the variable represents a map, a map of what? of assignments. Not of ‘assignment’. I think it’s a good convention to use.
I try to program by interface. It gives the code more flexibility. More details.
I have an issue however with the Java collections classes, which are always used. Checkstyle by default sets all implementing classes of the collections as illegal types. However, I don’t agree with it.
For instance: Set.remove(Object) makes no promises, it says it could simply throw a UnsupportedOperationException if the method isn’t supported. This isn’t usually a problem as most of the time the implementation is HashSet or possibly LinkedHashSet. Sometimes, however, I use ImmutableSet, which throws a UOE on remove. What I would like to do is return something which is a Set but which can be modified with remove.
Scala collections I think have a much nicer API.
For instance, Scala’s Set defines that the – method “Creates a new set with a given element removed from this set”, which is also the functionality of the mutable version (scala.collection.mutable.Set). The mutable version, however, also adds a -= method to modify the set in-place, something that only makes sense for mutable collections. But mutable.Set doesn’t define the implementation used, so it can be used as the type of any parameter or field that you declare to be a Set (no duplicate elements) and modifiable (-=, +=, etc).
If only, if only. If only Java’s collections had interfaces for mutable collections without implementation, that way I could return a MutableSet, leaving the user able to remove object (without having to create a new Set with the contents of the original Set), without having to specify the implementation..