DOA (Drawbacks of Acronyms)

More acronyms than you can shake a STIC at.

Recently I've been writing a system that performs reverse geocoding. It reads input from a GPS device over a serial cable and translates that to a human readable identifier of the user's current location. That sounds simple but my pair and I had a great deal of difficulty coming up with good terminology in our domain model. What should we call the type of values that the GPSReceiver object parses from the device's data stream?

Location? That wasn't right because we were converting GPS data into location information. Locations are named regions, such as rooms, buildings, post codes, wards boroughs, or towns, not points.

For a while we called them GPSCoordinates. But passing around single values of type GPSCoordinates read poorly. The mix of singular and plural didn't work. We considered LatLon, but not for very long: too ugly. We thought about Point, but that was too easy to confuse with 2D points. GeographicalPoint didn't seem right either.

Eventually we came up with the ideal name: Position.

And then we realised: GPS stands for Global Positioning System. If we hadn't been using an acronym in the name of the GPSReceiver class the correct name would have been obvious.

I usually try to avoid using acronyms and abbreviations as identifiers, except for really common ones such as URL, HTTP and GPS. But this has shown me that even the most common acronyms can befuddle my thinking about the application domain and software design.

Copyright © 2007 Nat Pryce. Posted 2007-03-05. Share it.

Comments powered by Disqus