Naming Conventions

The control naming pattern

Every control on a screen is named:

Pattern

Anatomy

• <type> is the lowercase control-type prefix from the registry below (lbl, btn, txt…).
• <Name> is a PascalCase role name describing what the control is for, not what it looks like (RecordTitle, not BigBlueLabel).
• <Screen> is the screen the control lives on, PascalCase with no spaces (Gallery, ItemForm, Loading).

Examples from the template

Inside a component, the suffix is the component

Controls inside a component are scoped to the component instead of a screen. For field components the <Component> suffix is the field type (Field<Type>).

The full field-component naming table lives in the field-styleguide.md; this doc governs the control-type prefixes it draws from.

Control-type prefix registry

The authoritative list. Every prefix here is one actually in use in the template source. When you add a control, use the matching prefix; if a control type isn’t listed, add a row here in the same PR so the next dev inherits the decision.

Containers and shapes

con_ names a layout region by its role: con_Screen_ItemForm (the root), con_Body_ItemForm, con_Toolbar_Gallery; inside a component, con_Wrapper_FieldText. Insert containers from the Studio toolbar as “Vertical container” or “Horizontal container” (the orientation-named items), not “GroupContainer” or “AutoLayout.” shp_ covers rectangles used as dividers and rules, e.g. shp_RowDivider_FieldText.

Components

A component definition is cmp_<Name> (cmp_Header, cmp_FieldText, cmp_ConfirmDialog). A placed instance keeps the same cmp_ name; on a form, field instances are named for their role: cmp_Title_ItemForm, cmp_Status_ItemForm.

Variable and token prefixes

• fx_ is everything declared in App.Formulas: design tokens (fx_Colors, fx_Sizing, fx_Typography, fx_Radius, fx_Spacing), schema helpers (fx_Blank<X>), and UDFs (fx_FieldIcon). Use these tokens everywhere; never hardcode a color, size, or radius literal.
• ctx_ variables are set with UpdateContext and live for one screen. The record-flow trio is ctx_SelectedItem, ctx_FormMode, ctx_SaveAttempted.
• gbl_ variables are set with Set and live app-wide. Prefer ctx_ unless a value genuinely needs to cross screens.
• ds_ prefixes a data source where an explicit reference name helps; SharePoint lists connected directly often keep their list name.

Casing rules

• Prefixes are lowercase, followed by a single underscore.
• <Name> and <Screen> segments are PascalCase, no spaces, no hyphens. A screen literally titled “Item Form” is referenced as ItemForm in control names.
• Segments are joined by underscores; words within a segment are not (RecordTitle, not Record_Title).

Known inconsistencies (grandfathered)

The template has a little legacy drift. New work follows the canonical choice; existing stragglers are flagged for cleanup, not left as precedent.

When to update this doc

Update this styleguide whenever:

• A new control type is introduced and needs a prefix — add the row here, in the same PR, before merging.
• A naming convention changes or a grandfathered inconsistency is finally reconciled — move it out of “Known inconsistencies,” or delete the row, once the source is clean.
• Another doc starts restating a naming rule — pull the rule here and leave a pointer there instead.