# Use naming conventions

It is important to follow some naming conventions when working in Create. At some point, you as a developer will no longer be handling and maintaining the application. Good naming conventions will make the transition of knowledge easier. In addition, good naming conventions will increase the development speed, since it will simply be easier to look up actions, user interfaces, and data sources.

This section is a suggestion from us in Appfarm based on our experience, and is not mandatory to follow. Most importantly: Have a naming convention that works for you, and make sure you and your team follow it.

## Object Classes

Object Classes are one-to-one with a database table. However, the naming of the object class should reflect the data stored in it, and it should be human-readable and understandable. In other words, use natural language with spacing between words. In addition, even though an Object Class may hold multiple instances, do not name the Object Class in its plural form.

{% tabs %}
{% tab title="Example 1" %}
You need an Object Class to hold invoice headers and it's rows. This in fact a hierarchy and the naming of these two objects should alphabetically be adjacent and both object classes should have the main purpose (invoice) as part of their name.

* Bad naming: Invoice, Rows
* **Good naming**: Invoice, Invoice Rows (or Invoice Header, Invoice Rows)
  {% endtab %}

{% tab title="Example 2" %}
You need to hold info on assignments, and each assignment may have multiple tags, a log, and documents. All these data are related to the Assignment, and all should be prefixed with *Assignment*.

* Bad naming: Assignments, AssignmentDocuments, Log
* **Good naming**: Assignment, Assignment Document, Assignment Log

In this example, these 3 Object Classes will be adjacent to each other when browsing the list of Object Classes, which makes them easier to find. And we can see that they are related, only by looking at the name.
{% endtab %}
{% endtabs %}

## Naming of Object Class Properties

We use the same principle for naming Object Class Properties, as we do for Object Classes. The names should be human readable, i.e. with spacing between words. In addition, if we have technical properties, such as date of approval and who approved, we normally use the same prefix for these properties.

{% tabs %}
{% tab title="Example 1" %}
The name of a company.

* Bad naming: CompanyName
* **Good naming**: Company Name or Name

In this example, we normally would just name the property *Name*, since the property is part of the Company, and we do not need to repeat "Company" in the property name.
{% endtab %}

{% tab title="Example 2" %}
Approval properties (2 technical fields)

* Bad naming: ApprovedBy, Date
* **Good naming**: Approved by, Approved date
  {% endtab %}
  {% endtabs %}

## User Interfaces

The name of a User Interface should reflect the data or purpose of the User Interface. There are in general two types of User Interfaces: Views and Dialogs. When browsing your User Interfaces, the Views will be sorted first (alphabetically), and then the Dialogs will be listed (also sorted alphabetically)

{% tabs %}
{% tab title="Example 1" %}
A View for listing all `Users` with functionality for adding, removing, or editing users

* Bad naming: Add Users
* **Good naming**: Users
  {% endtab %}

{% tab title="Example 2" %}
In a case-handling system, you have a view for listing and searching all cases, and a dedicated view with process support for handling your cases.

* Bad naming: All cases, My cases
* **Good naming**: Cases, Case Handling
  {% endtab %}

{% tab title="Example 3" %}
You have a dialog for adding or editing new or existing Users.

* Bad naming: User
* **Good naming**: New/Edit User

In this example, *User* is a bad naming because it implies a read only view of a single user. If you have a dialog for a read only view of a Company (e.g. a Company Card), you may name this dialog *Company* or *Company Card*.
{% endtab %}
{% endtabs %}

## Data Sources

When adding Data Sources to your App, its name will default to the name of the Object Class itself. This is fine if you only have one Data Source for each Object Class. However, in most cases, you will have multiple Data Sources for the same Object Class, at least for the core data for Apps of certain sizes.

{% tabs %}
{% tab title="Example 1" %}
You have a data source holding all Orders, and another holding only the selected order

* Bad naming: Orders, Order
* **Good naming**: Orders, Order (selected)

In this example, you see a few general principles we use. We use the multiple form of the Data Source has cardinality *Many*, and we add a short precision of the Data Source in parenthesis (e.g. Order (selected)), which briefly explains the data filter, since this is important information. The fact that the Orders Data Source many only hold Orders last year does not reflect in its name. However, if we had 2 Data Sources holding many Orders, we would add parenthesis to the Data Source names of these two as well.
{% endtab %}

{% tab title="Example 2" %}
We have a Runtime Only Data Source for creating new Persons. This is a Single Cardinality Data Source

* Bad naming: Person
* **Good naming**: Person (temp), Person (new/edit), Person (runtime)

In this example you see a principle we use a lot: Runtime Only Data Sources are always postfixed with a parenthesis with *temp* or *runtime* etc. When viewing e.g. a Data Binding in a User Interface, we can immediately see that a UI Component is bound to a Runtime Only Data Source. Even though the Runtime Only Data Source in most cases are grouped together when browsing the Data Sources list, a good naming will make Actions and User Interfaces more readable.
{% endtab %}
{% endtabs %}

## Actions

We use two principles here. The action names should reflect the purpose / what task the action performs, and similar actions should alphabetically be grouped together.

{% tabs %}
{% tab title="Example 1" %}
We have 3 actions for navigating from the menu to 3 different views.

* Bad naming: Orders, Users, Go to Companies
* **Good naming**: Nav - Orders, Nav - Users, Nav - Companies

In the above example, we prefix the navigational actions with "Nav -".
{% endtab %}

{% tab title="Example 2" %}
We have 4 actions related to manipulation of an Assignment

* Bad naming: Create Assignment, Save Assignment, Add document to assignment, Complete
* **Good naming**: Assignment - Create and Open Dialog, Assignment - Save and Close, Assignment - Add document, Assignment - Complete.
  {% endtab %}
  {% endtabs %}

## Action Nodes

In general, the names of action nodes are autogenerated (by the type of action node). But in general, we use the names of action nodes as a short description when the default naming is not self-explanatory.

An example of such is the IF-action node. If the IF-condition is a self-explanatory one-liner, we do not name it. But if the condition is complex, we normally add a short name serving as a description of when the condition should trigger.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.appfarm.io/how-to/data-modeling/naming-conventions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.