Naming Convention and Code Rules

Naming Convention: A naming convention is a set of guidelines or rules used to define how variables, functions, classes, and other elements in the code should be named. Consistent and descriptive naming helps improve code readability, maintainability, and collaboration among developers.

Naming Convention: variables might follow a certain pattern like camelCase (e.g., myVariableName), PascalCase (e.g., MyClassName), or snake_case (e.g., my_function_name). By adhering to a consistent naming convention, developers can easily understand the purpose and scope of different elements in the codebase.

Code Rules: Code rules, also known as coding standards or coding guidelines, are a set of principles that developers follow when writing code. These rules define best practices, coding styles, and guidelines that ensure a uniform and structured approach to coding across the entire software project.

Code rules may cover various aspects of coding, such as indentation, line length, comments, error handling, code organization, use of design patterns, and more. Following code rules helps maintain code quality, reduces bugs, and makes the codebase more maintainable and scalable.

Name Conventions

Type	Rules	Example
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 Description	Objects 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.
Rules
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!	QA_actionGetAddressFn DCM_CSCUseCache SMPL_readFileFromBuffer
Rule Description	Each 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 Placeholders	Rule 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.	v_caseTypeId v_caseId v_owner
SQL Code - Variable type	Variable type should use UPPER CASE;	NUMBER; NVARCHAR2(255);
SQL Code - Common structure of rule/function	The common structure of a rule or function should be like: SQL `DECLARE <declare local variable section> BEGIN <input paremeters init section> <init local variables section> <check input parameters section> <main section> <exit section> END;` This is a recommendation.	SQL `DECLARE v_caseid NUMBER; v_owner NVARCHAR2(255); BEGIN v_caseid := :CaseId; v_owner := SYS_CONTEXT('CLIENTCONTEXT','AccessSubject'); IF v_caseId IS NULL THEN EXIT; END IF; --<do something> END;`
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.

Name Conventions

Related Articles