We are starting to democratize application development at our company, allowing members of other teams besides tech to build and start using their own airtable applications and workflows before they are officially reviewed and onboarded onto our platform. However, the lack of the ability to enforce naming conventions across our workspace leads to all manner of strange table and field naming behaviors that make it jarring to move from space to space, as well as often ambiguous what the fields mean or are meant to be used for. It’s not pretty when one team decides they want to UPPERCASE ALL THEIR TABLE AND FIELD NAMES, while another decides to add dots.between.words.for.all.their.table.and.field.names.to.denote.hierarchies, with-dashes-and__underscores_and_(parentheses galore). Or decides to notusespacesbetweenwords or use abbreviations many may not be familiar with, making them far less readable (Qty instead of Quantity and POM instead of Point Of Measure). Or decides to name a field ‘Completed’. Does this field denote whether or not the record is complete, or the time the record was completed at? Although the field type icon is visible if the field is a checkbox or date field, it is not visible when a function field or lookup field is used, and certainly not visible when working with the API. A much better naming convention we are trying to enforce so that we immediately know what we are looking at is that basic True/False fields should start with ‘is’ (Is Complete), while datetime fields should end with ‘At’ (Completed At). Most people will do a combination of all of these, and are simply not consistent in their naming conventions. We are starting to socialize standard conventions that should be used when naming tables and fields – Camel Cased Words Separated By Spaces. However, many people at some point forget or neglect these conventions and only fix them once someone calls them out. What becomes particularly tricky is that fixing these names becomes much, much more difficult and time consuming down the line once someone has built an API integration that relies on that table or field name. Changing the table and field names may update the names anywhere they’re used in Airtable, but any and all programs and automations that use that table or field name directly will start to fail, unless they are all tracked down and updated by hand. We have faced this many times in the past, where changing a field name causes a chain of errors and problems to appear days later, and so most of the time we simply never rename fields that are likely heavily being referenced in programs and automations, no matter how many underscores, dots, or lack of spaces they have and how poorly they are named for what they actually track. While some naming conventions will likely always need to be socialized, like choosing a descriptive rather than abbreviated or ambiguous name for the data you are tracking, it would be very helpful to be able to set basic naming conventions for our workspace that get enforced whenever someone is naming a table or field. We want to make it as easy as possible for our users to do and build things well. Standard conventions and best practice should be baked in and opt-out, not opt-in!
... View more
