Syntax - Backend services

Overview

Syntax for services and code used in backend services deployed to AWS

Node

Code formatting

Indentation

• 2 spaces
• no tabs

New lines

• \n (unix style)

White space

• none at end of line
• do not indent empty lines

Semi-colons

• always add at end of statements

Quoting strings

• single quotes
• except in JSON or if string has single quote, can use double quotes then

Opening braces

• place on same line as statement
• correct:

if (true) {

• wrong:

if(true)
{

Closing braces

• else on same line as closing brace
• correct:

} else {

Declaring var

• one var declaration per line
• wrong:

var keys = [‘foo’, ‘bar’],
values = [23, 42],

Line length

• less than 80 characters

Declaring variables

• always declare constants using “const”, so cannot accidentally change
• variables usually declare using “let” which scopes to block where possible, “var” is function scoped

Functions

• In most cases use named functions

Naming Conventions

• name should clearly represent the object

Variables, properties, function names

• lowerCamelCase
• if array add “s” on the end
• no underscore/dashes, only A-Z/a-z

Class and module names

• UpperCamelCase

Constants

• all UPPERCASE

Misc

requires at top

• add all require’s at the top of the file

Boolean/null/undefined

• always set to true or false, not 0/null/undefined
• if we set something to empty use “null”
• undefined: only when a new variable has not been set yet

'use strict';

• all code should add the 'use strict'; expression at the top of code (under license but before requires)

Documenting code

• use JSDoc formating
• https://jsdoc.app/about-getting-started.html

Logging from code

• use izara middleware logs
• levels from least shown to most shown:
  • debug: the most detailed level, used when debugging an error
  • info: undesired situation, but is possible under normal conditions (eg request validation fail)
  • warning: unexpected situation, does not cause logic to fail (eg undefined instead of null)
  • error: critical situation that should not happen and causes logic to fail
• ? confirm or fix ? log methods cannot take pure objects, must wrap in a new object, eg:

log.error(anObject);

will not work, should be:

log.error({anObject: anObject});

Jest

• use “test” instead of “it”
• try to make the test name a sentence for readability, eg:

test(“xxx equals yyy”)

Errors

• When throwing an error, always create an Error object (don’t throw a string)

Database Syntax

Database tables

• UpperCamelCase table names
• name in plural (add “s” on the end) for main table, eg Products, child tables would remove the "s", eg ProductAttributes
• no underscore/dashes, only A-Z/a-z

Database fields

• lowerCamelCase
• if array add “s” on the end
• only A-Z/a-z, no dashes
• avoid underscores except when the field is a composite of multiple fields or variables, then use underscore to separate them

Project File System Syntax

Node modules (files)

• standard modules the perform operations prepend: Create / Update / Delete / List / Get
• object name use singular (no “s”), for directories and module names

Directories

• lowercase for standard dirs (src, app, __test__/unit/src)
• UpperCamelCase for Service specific dirs

Filenames

• UpperCamelCase for Service specific dirs
• industry standard for standard/system dirs

Lambda

Function Errors when Direct Sync Invoke

• If want to return an error to calling function, throw the error from the Lambda
• Our standard is to check for that error in middleware eg handleInvokeSync function:

/mnt/WebsiteData/httpdocs/00_shop/IzaraCoreServices/izara-middleware/src/middleware_service_requests/lambda.js