Business Objects

Objects and Attributes

Object names and attribute names should be nouns in UpperCamelCase, with the first letter of every word capitalized.

Use whole words — avoid acronyms and abbreviations, unless the abbreviation is much more widely used than the long form, such as Url or Html or Wot, or the whole word makes the name too long.

Case, CaseHistory, WorkItem
Object and Attribute DescriptionObjects and Attributes should contain sufficient description to understand the meaning of a specific BOM element to reduce the effort to understand the meaning and purpose of that element.

DocumentType attribute is used for business-defined types of documents.

The list of available values is managed via the Document Type dictionary.

Business Object Relationships

The relation should be nouns in UpperCamelCase.

  • Many-to-One relations should be named with the first child object name followed by the parent object name and then the Id (ChildObject+ParentObject+Id).
  • One-to-One relationships are considered to be Many-to-One relationships with a restriction on cardinality.

DocumentCaseId for many Documents to one Case relation.


Rule Name

The rule name must use the UPPER CASE PREFIX (DCM, CLB, SMPL, QA, CUST, SJ, etc.) follow by an underscore and then words in camel case.

The name of the rule should reflect a rule functionality.

Do not use numbers in a rule name like DCM_Rule12, SMPL_Rule5. This is a bad style!




Rule DescriptionEach rule should contain a detailed description explaining the rule's purpose and rule implementation comments.This function copies cache data into cache tables and back by Case Id
Rules Parameters

The currently proposed naming convention is UpperCamelCase.

The argument is that AppBase capitalizes all SQL output parameters to UPPERCASE.

Input, CaseId, TaskId

Rules PlaceholdersRule placeholders should use UPPER_UNDERSCORE_CASE naming convention.@RULEPLACEHOLDER@
SQL Code

SQL Code - Variable names

The internal variable names should be next: v_<entityNameOrSomething>. First goes the prefix that reflects the "variable", the following word describes an attribute: name or calculated value, logical, purpose, etc.




SQL Code - Variable type

Variable type should use UPPER CASE;



SQL Code - Common structure of rule/function

The common structure of a rule or function should be like:

  <declare local variable section>

  <input paremeters init section>
  <init local variables section>
  <check input parameters section>
  <main section>
  <exit section>

This is a recommendation.

v_caseid   NUMBER;
v_owner    NVARCHAR2(255);

v_caseid := :CaseId;
v_owner  := SYS_CONTEXT('CLIENTCONTEXT','AccessSubject');


--<do something>


SQL code - Restrictions and recommendations

  • Do not use input parameters through the body of the rule. This is a bad style of code and it is inconvenient during refactoring
  • Always initialize a local variable
  • Do not reuse a local variable (v_result) for different situations. For example:
    • Bad style: SELECT COL_CASEID INTO v_result FROM TBL_CASE;
    • Good style: SELECT COL_CASEID INTO v_caseId FROM TBL_CASE;
  • Try to handle errors as much as possible
  • Try to avoid using numbers as part of the variable name: v_result2, v_result15
  • Give your variables context to improve code readability
  • Add comments. Use single comments for one row (–) and multiple for many rows (/* */)
  • Do not use a single comment for multiple rows.
  • Do not write a SQL code "too wide". Max of length is 150 symbols
  • Add empty rows between logical operations (code blocks)
  • Use v_result as a result of function execution. This is good for debugging and fast refactoring.
  • Do not use many variables with the same name such as v_res, v_res1, v_resultOfFunc, etc.