Loading...
 

Introduction

Every organization should come up with its own naming conventions; the naming conventions described here are recommendations that can be used as a starting point for new projects.

The format of names has no functional impact on the system; the naming convention should provide consistency and clarity of implementations and configurations across development releases and therefore helps to reduce long-term development and maintenance costs.

Qore Naming Conventions

  • ModuleName
  • function_name
  • methodName
  • variable_name
  • classVariableName, staticClassVariableName
  • CONSTANT_NAME
Camel case names should have the first letter of each word or acronym capitalized; ex:
  • HtmlClass
  • DbInterface
Note: for unused variable it is commonly used _ (e.g. int sub foo(int x, auto _) { return x + 1; }

See Qore Naming Conventions in the Qore Programming Language Wiki for more information.

Qorus Naming Conventions

Qorus Objects

  • WORKFLOW-NAME
  • service-name
  • job-name
  • mapper-name
  • INTERFACE-GROUP-NAME
  • tests: should have the same name as the interface being tested without the version number in the test file name

Qorus File Naming Conventions

Qorus files should define generally only one code object; exceptions can be made when code objects are always loaded together, such as multiple code attributes of a single step. This is to avoid refreshing (and therefore appearing to affect) interfaces not actually affected by a particular change to ensure that regression testing is only performed on objects actually affected by a change. If multiple independent code objects are defined in a single file and the file is loaded, the list of refreshed objects would be larger than the list of objects actually affected by the change.

All objects except tests should contain the version number in the file name, the only exception where the version may be omitted is v1.0 as this is implicitly expected.

Workflow Function Files

If workflow functions are delivered as separate files, then the files should have the same name as the function defined in it with the version appended (if version is different from 1.0) as in the following examples:
  • it_32_init_vms.qfd
  • it_32_init_vms-v1.0.qfd
  • it_32_init_vms-v2.0.qfd

Step Function Files

When step functions are delivered as one file per step, then step files should have the same name as the primary step function. If a step has multiple functions (primary, validation, array, back-end, etc), then all functions can appear in the same file; ex:
  • it_32_update_oracle_apex-v1.0.qfd

Library Files

Library files should have the same name as the library object defined (function, class, or constant). Only one library object should be defined in each file unless the library objet is a part of the fundamental infrastructure for a project.

Service, Job, and Mapper Files

Service, job, and mapper files should have the same name as the object defined, and only one object should be defined in each file.