A few days ago, I had a conversation with a customer regarding naming. They had created a file containing definitions for numerous tables and their corresponding column names for a new user interface. Some names consisted of entire sentences, with words like “from” and “to“.
I found myself dissatisfied with some of these names and thought about why I don’t like them and how to make them nicer.
Guidelines for simplifying names
To me, column names should resemble key points rather than complete sentences. So I’ve compiled a few guidelines that can help you in transforming sentences to key points.
- Eliminate filler words: Remove words like verbs and adjectives if they don’t carry relevant information.
- Remove articles.
- Remove words without additional information. For example, if the information is already included in another word.
- Remove information already included in the table name.
- Sometimes it makes sense to change the order of the remaining words.
An example
In our example, the table name is “CW 39” and the column name is “The only day of Monday of CW 39 before CW 40“.
1. Remove all filler words:
The information about there being only one Monday per week is widely known and unnecessary here. Therefore, the new column name is:
“The day of Monday of CW 39 before CW 40“
2. Remove articles:
The article “The” can be removed. So the new column name is:
“Day of Monday CW 39 before CW 40“
3. Remove words without additional information:
The information that it’s about a day is already part of the word ‘Monday’. It’s also obvious, that CW 39 comes before CW 40. So the new column name is:
“Monday CW 39“
4. Remove information already included in the table name:
The table name “CW 39” already tells the reader that all columns contain information on this CW. So the new column name is:
“Monday“
It is much better to read, isn’t it?
Conclusion
After the reformatting, the table became significantly smaller. The names are easier to read, and the understanding is faster as there’s no need to decipher the true meaning within a lengthy sentence.
Thus, it’s a huge advantage to keep the names as short as possible without losing essential information.
Schneide Blog 
Are these rules in anyway specific to column names of user interfaces? For me these rules sound familiar from general naming rules given a certain context. Let’s say naming a local variable inside of certain method, class and package.
The rules are initially set up for column names of user interfaces. This does not mean that they cannot be applied to other naming schemes.