Syntax - Backend services: Difference between revisions

From Izara Wiki
Jump to navigation Jump to search
(Created page with "= Overview = Syntax for services and code used in backend services deployed to AWS = Node code formatting = == Indentation == * 2 spaces * no tabs == New lines == * \n (...")
 
No edit summary
Line 70: Line 70:


* In most cases use named 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
= 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:
<syntaxhighlight lang="JavaScript">
log.error(anObject);
</syntaxhighlight>
will not work, should be:
<syntaxhighlight lang="JavaScript">
log.error({anObject: anObject});
</syntaxhighlight>
= Jest =
* use “test” instead of “it”
* try to make the test name a sentence for readability, eg:
<syntaxhighlight lang="JavaScript">
test(“xxx equals yyy”)
</syntaxhighlight>
== Errors ==
* When throwing an error, always create an Error object (don’t throw a string)

Revision as of 00:51, 3 September 2020

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

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)