Ways to name your elements properly

Hi guys,

After months of research and application in real projects. We have come up with interesting ways to name elements. Here’s an analysis and guide of ours on how to name your database.

Data type

PascalCase should be used for data types.

Why? We saw that Bubble used a lot of natural languages in its builder. That is easy to understand, as the tool is aimed at citizen developers. The use of words without spaces helps differentiate the data types from native types and other phrases that Bubble uses.

Why not snake_case like in regular databases? Bubble automatically capitalizes the first character of the data type in the builder, and Snake_case looks weird.

Some notices on choosing names:

As data types represent “things”, their names should be nouns or compounds of nouns. They should be singular as well, as a data type represents the blueprint of 1 singular thing. Bubble also adds s 'es to the end of the types when you are retrieving a list of them, so a type of Cars would become Carss and that’s just weird, unless you try to make it badass.

|100%xauto

An example of using CamelCase for data types

Data field

camelCase should be used for data types.

This is a common presentation used for variables in regular programming, so we thought a resemblance would be good for developers to work with. Moreover, it looks similar to data type’s PascalCase, implying their relationship.

Some notices on choosing names:

Data fields vary in forms and usage. The approaches for each type are as followed:

  • Text, file, image, date, address types: These types can be represented by nouns (e.g. username, homeAddress). If the field is a list of objects, you should use the noun’s plural form.

  • Number: You should add a word indicating that the field is a number field to help differentiate it from the others. For instance, a field counting the number of cars can be noOfCars or carsCount.

  • Yes/no (aka boolean): We took this one from the best practice in pro-code. It is recommended to use auxiliary verbs to indicate the dichotomy of the attribute. For example, if a blog post can either be private or public, you can use either isPrivate or isPublic to indicate the privacy*.* This is not a perfect approach as you will see Bubble’s builder refering to the field as This Post’s isPrivate , which is not grammarly correct, yet it is easier to understand the purpose of the field.

  • Relationship (a field that refers to another data type): We have 2 recommended approaches for this type of field. You can either use nouns like usual, or you can use verbs to indicate the relationships between the 2 data types. For example, for a nested comments structure, you can refer to the parent comment as parentComment , or repliesTo, as this comment replies to its parent comment.

|100%xauto

An example of naming data fields

Other recommendations

Sometimes we have fields and types that are used for management on the system level and are not visible to the users and should not be manipulated by the users whatsoever, as they are critical and sentitive. We would not want other developers to mess up those fields as well, hence the need of differentiation. An example of this is the case of multi-tenancy, as you may have fields to control privacy.

In this case, it is recommended to add an underscore ( _ ) in front of the types and fields. This pattern is widely seen in traditional coding as well.

|100%xauto

An example of data types used for system tracking

|100%xauto
An example of using a field for multi-tenancy (contacts are scoped inside companies)

Airdev (a well known Bubble delivery vendor) usually uses Unicode icons (aka characters, aka emojis) like :gear: instead of using underscore. This is not a bad approach at all and it is way better than underscore in terms of visibility, however typing _ is quicker than having to input such an icon. You can feel free to explore and use the method you prefer.

Sometimes you might have fields or types attached to different actors in your application that you would want to differentiate. In this case, having a [Tag] in front of the fields or types would help.

|100%xauto
An example of using tags


This is just one part in our Bubble Naming Convention, which can be found here. Please let us know your thoughts! Comments will be great motivation for us to continue develop the document.

Thanks!

1 Like

This is a handy dandy tip. I have my own silly namings that I’m used to but i think it’s handy nonetheless.

I would like to share how i categorize my states. I store all my states in groups that all start with a #. It’s easy to reach for # on a keyboard.

For example I have all my data states in #data and all my loading states in #loadingStates

3 Likes

That’s great to hear!

I agree # is indeed very handy for navigating states. In the document, we did also provide some ways to navigate elements with not just states but also data and clickable:

  • <S> or <State> for elements with custom states.
  • <D> or <Data> for elements with custom data sources (parent elements only, no need to mark child elements that inherit the data).
  • <C> or <Click> for non-input elements that are clickable (e.g. texts, groups).

Nonetheless your approach is totally great! I will research and see if using @ # $ for labeling rather than tags like the one above makes more sense.