Top-level definitions

The sections below include the coding conventions with respect to top-level definitions.

General practices

  • Do not indent the top-level definitions.

Do's

Don'ts

Import declaration

  • Do not keep spaces between the organization name, divider /, and module name.

Example,

  • Imports should be sorted alphabetically, first by the organization name and then by the module name.

Function definition

  • Do not keep spaces between the function name and the open parentheses ( of the function signature.

Example,

  • If the function needs to be split into new lines due to it exceeding the max line length, you can break lines from the parameter list by moving only a parameter value to a new line and indenting it with four spaces from the starting position of the function.

Example,

  • You can break before the returns keyword and indent it with four spaces from the starting position of the function.

Example,

  • You can break after the returns keyword by moving the return value to a new line and indenting it with four spaces from the starting position of the function.

Example,

Service definition

  • Keep the listener inline with the service signature.

Example,

  • When formatting service-level method definitions, block indent each element and follow the Function definition formatting guidelines.

Example,

  • Block indent each method definition, and field definition inside a service definition.

Class definition

  • Block indent each field definition, method definition and type inclusion on their own line.
  • The init method should be placed before all the other methods.
  • For method definitions in the class definition, follow the Function definition formatting guidelines.

Example,

Record definition

Block indent each of the field definitions (including the rest field) in their own line.

Example,

Reference record or object

  • Do not keep spaces between the * and the object name or the record name.

Example,

  • Also, block-indent.

Example:

"Star"

"Watch"