If there is one thing that separates modular software from one-off/spaghetti/ravioli code, I suggest it is in the choice of names. It is hard to consistently assign good names to software abstractions, yet the payoff is large.

I see good naming as a prerequisite for the success of any software development methodology. When I practice extreme programming, if I don't slow down enough to think of a good name for classes, functions, and variables, the code quickly becomes sloppy. If it's too hard to think of a good name for some concept, I reconsider the usefulness of that concept. If I can't name it, I won't write it, and I move on to something I can name.

When I understand some intended piece of functionality very well, I already know what to name everything, so the fingers fly and coding is easy. However, when it's that easy, there's a good chance the code I'm writing duplicates something that has been done before. Other times, the system I'm building is so abstract that I have to invent a new naming system--and that's when I have to be really careful not to become an architecture astronaut.

The best times are when I name and code a few functions, get stumped for a while on what to name something, work on something else for a while, then later solve the naming problem. When I'm in that mode, I feel confident that my work is both original and applicable to others. I feel like I'm learning something and maybe even teaching others.

Some examples of good and bad naming:

• The Python standard library has carefully chosen names so that developers don't have to hunt the documentation very often. As a result, programmers consistently take good advantage of the standard library.
• javax.imageio is easy to use if all you want to do is load or save an image. If you want to do something slightly out of the ordinary like embed a comment in an image, you have to wade through deep piles of soundalike names. I tried to make sense of the API, but the naming scheme gave me the impression that the authors didn't really understand the abstractions either. (GraphicsMagick saved the day.)
• I like web software that uses short, readable URIs. I avoid web software that treats URIs as some kind of opaque digital code. An opaque URI suggests a hollow vision of the Web. Users depend on good URIs to decide whether the URI is permanent, trustworthy, linkable, bookmarkable, cacheable, unchanging, and so on.

I wonder if anyone is working on a general method of naming abstract concepts in software. In the meanwhile, choosing names is an art, and all I can do is collect a list of basic naming rules, starting with:

• Metaphor is useful but often abused.
• Verbosity clouds the code.
• Terseness sometimes becomes DWIM.
• Don't suffix class names with "Manager" or "Info".

I found a list of other useful rules collected by Tim Ottinger.