Re. Schema, Design, and Preferences

[Ben_Young1]

A Quick Prelude

This morning, I was blankly staring past my monitors in a strange state of disassociation.
On my screen was the commit history of a substantial git repo.

While clearing out stale branches, I went down the rabbit hole of examining each engineer’s stylistic approaches.

Commenting out versus deleting old code.
Writing references to previous commits in comments.
How some engineers write intuitive variable and function names, while others might name them rather generically.

While some of those examples get called out and corrected in PRs, it left me with a lingering curiosity about our stylistic and functional choices when working with Airtable.

---

This is a rather open-ended discussion, but I wanted to open it up to see how everyone likes to do things.
It could be anything.

There are some things that I’m personally curious to know, but I’d encourage anyone to jump in and share anything that you keep in mind when you are planning, building, implementing, and working within Airtable.

Some things that I’m particularly interested to hear about:

• Formulas

  • What stylistic preferences, if any, do you have in writing formulas?
  • Do you prefer some functions and operators over others?
    • What do you use most?
    • What do you never use?

• Bases, Tables, and Syncs

  • How do you map and think about new bases and tables?
    • Beyond best practices, is there anything that you altogether avoid doing?

• Fields

  • Any field types you avoid like the plague?
  • Any workarounds that you prefer to use instead?

---

I tend to be fond of the experience of finding forum posts from 2005 for software on version 1.2.16 and then using what I find to fix the behavior in the latest version sitting at like 17.8.21a.

I’m a huge believer in the necessity of precedent.
While I am curious to see what everyone might share, I’m also distantly hoping this thread might provide a lot of insight for users down the line.

[kuovonne]

This is a bit of rambling while I am sitting in my car waiting for my daughter.

I’ve developed a particular style of writing formulas that works well for me. I have seen more and more other people post formulas with a similar writing style. I won’t go so far as to say who is copying whom or if we have all evolved out styles independently. I know that my style is heavily influenced by looking at code in other languages and I put a lot of thought into how I want to style my formulas.

My formula style has evolved over the years and I still adjust it slightly every now and then.

I used to rarely use CONCATENATE and used & almost exclusively. I now use both quite frequently in conjunction with each other.

The one formula that I commonly see used but I never use is BLANK(). There are several other formulas that I never or rarely use, but it seems that hardly anyone else uses them either, so they aren’t worth mentioning.

As for field types—I used to avoid lookup fields whenever I could use a rollup instead. Rollups simply behave better in formula fields. But I am coming around to using lookups of collaborator fields and single select fields more and more. I think this is related to Interface Designer.

The main field type that I always think long and hard about before using is the multi-select field. I do use it occasionally, but only if I am sure that the field should not be a single select or a linked record field.

When designing a base I spend a lot of time thinking about where I want to put each piece of logic. There are so many places.

• Do I want to use an automation or a scripting action?
• Do I want to trigger an automation by watching for any change or by watching for a specific condition?
• Which parts of the automation do I want to put in a script and which parts do I want as non-scripting actions?
• Do I want a valued to be calculated in a helper formula field or in a script?
• Do I want to put filtering logic in a view or an automation condition or in a script?
• Can I make a formula field do double duty to both trigger the automation and provide a useful input value to reduce the total field count?
  And that’s not even getting into third party integrations.