Even when we try to discuss a nameless thing, we apply a pseudo-name to allow us to articulate our thoughts. The “pink place,” “the big, big road,” “the evil-looking tree” …. To discuss a thing, it must have an identity. A name supplies an identity for a thing. Once named, we may now speak of it. The bedrock of any good set of standards starts with names. Regardless of the role we may play in managing technological solutions, everything needs a name because everything will be discussed.
Standards for naming are generally simple arrangements. They may start by having a qualifier and a base object name. Then get a bit fancy by allowing there to be multiple qualifiers. This can take us from a “red apple” to a “shiny red apple” to a “formerly shiny, now rotting red apple.” Naming something by just a base name and nothing more is dangerous. An “apple” leaves so much more to be assumed that it should be expected that two different people will have two completely different ideas. In some simple conversations, one may use the base name alone, safely, because the conversation itself has already provided the context to allow people to align the idea. But as a proper name, qualifiers do serve useful purposes.
In addition to qualifiers, one may look at additional elements of a name that can help everyone to understand. This is where a naming standard may aid in high-level categories, or low-level classifications. How many of each depends on the kind of object being named and the suspected needs. For instance, in a dimensional data mart it may be considered desirable to have a dimension/fact categorization for tables, as in “dimension day” or “dimension customer” or “fact order.” Care should be given to those things that names will start with as one needs to consider how these names will sort as a group. Would a general subject area be a good aspect to see or not? Often when dealing with individual data items, attributes or columns, a class word is used to identify the domain—“customer name” or “mailing address zip code” or “immediate reorder flag” and so forth. How many of these categories and how many classifications you use will all depend on the complexity and needs of the objects being described. However, just stringing together the few pieces discussed above, subject area/category/[qualifier]/base object/classification, serves as a robust naming standard option that may cover a large namespace.
Beyond the above-mentioned elements, one may dabble into standardizing the case to be used for names, camel-case (camelCase), snake-case(snake_case), kabob-case(kabob-case), or there are a few others. Going further, one may wish to advance into the often hotly debated issue of abbreviations. One issue that is sometimes tender is the actual abbreviation to employ. Is “name” abbreviated as “nm” or “nme”? Is “number” best abbreviated as “num” or “nbr”? It is surprising what issues may result in disarray. Another possibly contentious abbreviation issue concerns when, and when not, it is appropriate for an abbreviation to be used. And even when people agree, finding the best way to express these choices in one’s standards document also may prove challenging.
Naming standards do not need to be complex, and they do not need to be time-consuming to define. But these standards are necessary; and it is important that they not only be in place but be in a place that is easily referenced by the entire solution team. Additionally, it should be clear as to whom it is best to go to with questions or concerns. Transparency and ease of use are the best possible qualities of standards. Starting a naming standard can be as simple as starting to list the objects that engineers, designers, and architects will be creating.