Naming Conventions

Class Naming Conventions

Class Type Prefix Notes
Code c
  • rarely used
  • Legacy exceptions for UpgradeRoutines and Common
  • specifically used as a broker between web sales GUI and remote tasks/objects
File f or F
  • any new file classes start with 'f'.
  • Legacy File classes from Omnis Classes start with F_
  • pg for PostgreSQL system tables
Menu m
  • Legacy exceptions for STARTUP
Object o
  • Web listener objects: oWebCom
    Asynchronous objects: oAsync
  • (Exception for Database DAM’s, which must be named the same as the DAM they inherit from.  E.g. PGSQLDAM, FRONTBASEDAM)
Query* q
  • Reports query classes: qr
Remote Task rt  
Report r  
Schema s
  • Generally same as the File class it is based on, just prefixed by 's'
Table* t
  • Reports table classes: tr
Task none
  • there is only one real task in theatre Manager that must be called 'Startup_Task'
Toolbar T_  
Window w
  • Modal message windows: wMsg
  • Windows used for Sub-Window toolbars: ST_
  • Sub-windows used as part of a large complex window should be prefixed with the name of the large window they are part of.  Examples are wReportParam, wSell, wSearchSubWindow, wClient.
  • Windows should end in the suffix 'Detail' or 'List' and follow a similar naming convention to the table class they are based on if they are the standard detail or list window for any given table class. e.g The list and detail window for tfResources is wResourceList and wResource Detail. The list and detail window for tfResourceLink is wResourceLinkList and wResourceLinkDetail.

*Query class names should match the corresponding table class. E.g. tClient and qClient.

Data Dictionary

  • All file classes (database tables) used for the Theatre Manager database must be assigned a unique prefix in the Data Dictionary. For example, F_CLIENT uses C_, F_PLAYSEATS uses PS_. There are several essential parts of Theatre Manager that rely on this naming convention for automatic foreign key determination.
  • All primary key records are named with the prefix for the file class (database table) followed by SEQ. The primary key for F_CLIENT (C) is C_SEQ.
  • All foreign key records require the use of the unique prefix within the name, as well as the suffix _SEQ. For example the F_CLIENT (C) foreign key on the F_PLAYSEATS (PS) record is PS_C_SEQ.
  • If the user should not ever see a column, then it should be marked as internal. It is not required to enter a description for internal fields.

Method Naming Conventions

  • Methods are named with camel case beginning with a lower-case letter. E.g. $myMethod
  • A method used for a button behavior should begin with $clickBtn. E.g. $clickBtnBuyTicket
  • getter methods should start with $get (eg $getCurrentColour)
  • setter methods should start with $set (eg $setCurrentColour)
  • group similar function methods under a dummy header method with a name that starts with some ---- eg '---- Window Open Methods ----'

Variable Naming Conventions

All variables should be named using camel case rather than hyphens or underscores. E.g myVariable or MyVariable instead of MY_VARIABLE.

However, if is a parameter, local, or instance var that is meant to track a cope of a database SEQ key, then call it what it is. eg pM_SEQ means that the parameter we expect is an M_SEQ key. This helps with variable assignment.

All database names will be named using underscores and in UPPER_CASE to make an obvious differentiation between the database and other task/class/instance/local variables.

Scope / Type

 Prefix

Convention

Task

 t

 

Class

 c

 

Instance

 i

 

Local

 none

Developer preference, prefer myVariable rather than MyVariable.

Parameter

 p

 

Constant

k
  • Developer preference
  • prefer prefixing with k.  E.g. kNameOfFile
  • Scope left to developer preference