LCS - Naming Conventions for Betty Blocks Development

A standardized convention for naming while developing applications in Betty Blocks. 

Pascal Case

Examples: ProjectUpdateForm (component), ProjectUpdateRecord (action step), OrdersCount (action step)

  1. All PB (PageBuilder) components – except for box, grid, row, and column.
  2. All Action Steps

Note: Every component (which may potentially be referenced) should have a unique name that identifies both the content and type. This will allow each to be easily identified in a list where you have no context for its location. e.g. AddProjectActionButton, PageTitleText, ProjectDataList.

Snake Case

Examples: project_id, comment_id, customer_name

  1. All variables on pages and in actions
  2. All Data Model Property-Database Names (which appear on the Advanced drop-down of the Data Model Property detail) -- automatically done for you by BB.
  3. All Relationship-Database Names (which appear on the Advanced tab of the Model details) -- automatically done for you by BB, but for the following two exceptions (where you must provide the snake-case relationship name manually):
    1. When a model has a self-referencing relationship; this situation requires renaming the "Has Many" relationship as the "parent"', and the inverse "Belongs To" relationship as the "child".
    2. When a model has multiple relationships to a particular model; this situation requires renaming them to specify the purpose of each. For example: the WebUser model has two connections to the Project model, the first to capture who created the project, and the second to capture who is assigned to lead the project. In this example, you might name the relationship database names as, "created_by", and "assigned_to".

Title Case

Examples: Project (Model), Project Tasks (Model, Relationship), Customer Order Number (property)

  1. Applies to all Model, Model Property, and Model Relationship names.
  2. Model relationships are automatically named by BB and should not be changed, but for the following two exceptions:
    1. When a model has a self-referencing relationship; this situation requires renaming the "Has Many" relationship as the "parent"', and the inverse "Belongs To" relationship as the "child". Example names include be "Parent Comment", "Sub Comment" and "Child Comment".
    2. When a model has multiple relationships to a particular model; this situation requires renaming them to specify the purpose of each. For example: the WebUser model has two connections to the Project model, the first to capture who created the project, and the second to capture who is assigned to lead the project. In this example, you might name the relationships, "Created By", and "Assigned To" (using the Title Case style).

Normal Sentences with this convention

[PB/SUB/BO/SYSTEM] Page Name – Detail information about the page or action.

Examples:

  • Pages
    • [PB] Items - Overview
    • [BO] Item
    • [PB] Items - Detail
    • [SYS] Login
  • Actions
    • [SUB] Create Item
    • [BO] Item - Update Form
    • [SYSTEM] Email configuration
    • [PB] Items - Overview - Create Form
  1. Applies to all page names and action names.

Definitions

  • Pascal Case - A method of naming that capitalizes the first letter of every word and only uses characters a-z.  Ex: “PascalCase”
  • Snake Case - A method of naming that utilizes “_” in between each word as a separator.  Ex: “snake_case”
  • Title Case - A Method of naming that capitalizes the first letter of every word and separates words using a space.  Ex: "Title Case"
  • System - A page, or Action that is universal to an application, or an application template, and should not be modified by developers outside of the LCS Service Team. Abbreviation: SYSTEM/SYS
  • Back Office - A page that is used for back-end data entry or management. Abbreviation: BO
  • Page Builder - A page that is focused on front-end user interaction. Abbreviation: PB
  • Sub Action - An action that is built to be reusable for other actions to call. Abbreviation: SUB
  • Self-Referencing Relationship -  This is when a model has both a "Belongs To" and "Has Many" relationship with itself. This is often used when a model might have sub items of the same type as it. A common use case is for comments,  where someone might make a comment on another comment. 


Keywords:
best practice, standards 
Doc ID:
133283
Owned by:
Joel H. in Low Code Solutions
Created:
2023-12-08
Updated:
2024-09-30
Sites:
DoIT Enterprise Business Systems - Low Code Solutions