Naming conventions in Claris Studio

People give all things a name. Naming things is a way to give order to the world. It also helps other people to know what you are referring to. In science, the classification of species is called a taxonomy.

In any software development project, giving things a proper name, is also of crucial importance, for much of the same reasons. Don’t tax your taxonomy and make use or our experience.

At OpenC we apply a consistent and documented system for naming things in Studio (and in the rest of the Claris platform). Here is a summary of the rules of thumb we apply:

Edit (Jun. 10, 2025): Thank you for all the good feedback with which we could improve this guidelines! You will find the new version below.

Studio name — make it short and sharp, e.g.: OpenC DEV

Important when you have to manage and develop several Claris Studios and switch between them.

User names — include the department or organisation name, e.g.: Remco van Buren of OpenC

There is no description field for the user, at the time of this writing. So we include the name of the organisation in the User name. We also add the word ‘of’ because sometimes we user that account name on a View, like this: ‘Hi Remco van Buren of OpenC!’ That makes more sense then something like ‘Hi OpenC | Remco van Buren!’

Group names — include the role, e.g.: OurClient, Users

In Claris Studio there is, as of 2025, no description field for a Group, at the time of this writing. That is why we put a description of the user role into the Group name field.

Hub names — keep the user in mind, e.g.: Your Clients

If the user has Member rights, and logs into Studio, and then it must be immediately clear what the Hubs they have access to, mean to them. Examples of hub names: ‘Sales funnel’ of ‘Project AI’.

View names — short and meaningful for the user, e.g.: Your Clients Form

The tile of a View indicates what kind of View it is. For example, a Spreadsheet View is a green tile with a table-icon in it. A Form View is a mid-blue tile with a form-icon in it. But still, at OpenC we put the name of the View type into the description, at the end, without the word ‘View’. Some examples:

• Clients Sheet (Sheet as a shorter word for Spreadsheet View).
• Clients Form (for Form View).
• Clients CV (for Custom View).
• Clients Media (for Gallery View).

Frame — this functionality is yet to come, we’ll add our guidelines at a later moment

Table names — Begin-capital and in plural, e.g.: Clients

When a table is created in Studio, it gets a default name such as Spreadsheet16. Change it, otherwise it will be hard later on the select the right table, in Studio calculations or in Claris Connect flow steps.

Field names — apply the the snake_case method, e.g.: client_name

This world is full of all kinds of conventions for naming things: Sentence case with spaces, lowercasewithoutspaces, camelCase, PascalCase, snake_case, and, frankly, SCREAMING_SNAKE_CASE. At OpenC we have decided to use the lower case snake_case. This method has several advantages:

• Simply omitting the spaces could lead to ambiguity. Take itscrap as an example: was it “IT scrap” or “it’s crap”?
• Even if using lowercase would not be ambiguous, snake_case is more clear, especially for people whose native language is not English. snake_case is the only method that really shows where the spaces were.
• Given that we do not use spaces in field names, we do not have to use quotes in Studio calculations. Compare tasks.due_date.value with Tasks."Due Date".value.
• It also improves readability in Claris Connect: compare Fields.email_address.Value with Fields.[Your e-mail address].Value.

You are right to point out that PascalCase and snake_case behave in roughly the same way when it comes to indicate where spaces were, but we prefer snake_case. In our opinion, PascalCase still leaves too much choice for the developer: “should I write JSONField or JsonField?” Chances are we end up with both variants, and then our convention would miss the mark – while enforcing the snake_case convention would result in everyone writing json_field, regardless of personal preference.

Object names on Views — Put the field name and the object type in the Object name, e.g.: client_full_name_shorttext

Always give the Object a proper name. We include the field name, then one underscore and then the object type. Other example: client_list or client_sheet.

Display labels and placeholders – be clear to the user

The Display Label instructs the user what to enter. It should be to the point, so that the user knows what to enter.

The placeholder can further assist the user: it can contain an instruction such as ‘Enter your name’ or it can give an example.

If it does not add value to the user we leave the placeholder empty. The user then has to read less text, and it gives a cleaner look to the screen.

As a bonus, here’s two more guidelines we apply at OpenC:

• In Studio, we only use number fields if we need a field for numeric calculations, such as add or divide. If we need a field for a status code, such as 0, 1 or 2, we never use a number field, because these codes are not arithmetic values. Hence, we use a short text field for those.
• Be aware that field names and also field descriptions cannot be labeled on screen, in certain objects, such as a Spreadsheet Object. These objects show the field name and description, e.g. client_name. If that’s a problem for your users, you have to rename the field to Client name for example.

Want to know more?

Download the OpenC guidelines here. This document contains some screenshots and a little more details, for clarification. Apply the OpenC naming conventions guideline for Claris Studio, or adopt them to suit your needs and those of your clients.