c Bluewolf, an IBM Company 2016-2017

c Copyright IBM Corporation 2018 — All rights reserved

Bluewolf Salesforce JavaScript Standards v0.1

Date: May 17, 2018
Contents

Contents ii

1 Introduction 1

2 Coding Style 2
2.1 Purpose of this section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Logic Guidelines 4
3.1 Async Await Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

ii
Chapter 1

Introduction [Intro.Scope]

(1)
The language in this document follows the ISO Directive standards as such:

• “shall” indicates a requirement

• “should” indicates a recommendation
• “may” is used to indicate that something is permitted
• “can” is used to indicate that something is possible, for example, that an orga-
nization or individual is able to do something
In the ISO/IEC Directives, Part 2, Seventh edition, 2016, 3.3.3, a requirement is
defined as an “expression in the content of a document conveying objectively verifiable
criteria to be fulfilled and from which no deviation is permitted if compliance with
the document is to be claimed.”
In the ISO/IEC Directives, Part 2, Seventh edition, 2016, 3.3.4, a recommendation
is defined as an “expression in the content of a document conveying a suggested pos-
sible choice or course of action deemed to be particularly suitable without necessarily
mentioning or excluding others.”

1
 Chapter 2

Coding Style [Style]

(2)

2.1 Purpose of this section [Style.Purpose]

(2.1)
This section is designed to recommend a uniform coding style for all Bluewolf JavaScript
development. Due to the rapidly changing nature of of both ECMAScript (JavaScript) and
increasing browser support of features this section will need rapid and repeated updates over
time.

2.2 Declarations [Style.Declaration]

(2.2)
1 Variables shall be declared using let or const.
All major browsers support both let and const, including IE11. Using let and const
allows the developer to be clearer in expressing their intentions. let and const declared
variables are block scoped and will cause an error if they are referenced prior to the declaration.
2 Developers should favor declaring variables as const.
const prevents the reference from being modified. This makes it harder to accidentally
assign over a reference that was not intended to be mutated. const does not however prevent
modification of an object assigned to a const variable.
3 When declaring a variable using let or const the variable shall be declared at first use.
4 Variables shall be initialized at declaration.
5 Object literals shall not be declared with duplicate keys.

Example:
const bar = {
f o o : ’bar’ ,
f o o : ’bafoo’
};

The problem with this code is that it confuses what the definition of foo is in the literal.
The browser will only keep the last value associated to that key in the literal.

2
6 Globally visible page logic should be in a namespace.
Putting externally visible logic in a namespace reduces the likelihood that there will be a
conflict with other code. Moreover it makes it clear where a method originates and thus what
file owns it.

Example:
// Create bar namespace if it doesn’t
// exist or extend the existing one.
const bar = bar | | { } ;
( function ( barNS ) {
’use strict’ ;
barNS . f o o = {
// Declaration style for IE11
doSomething : function ( ) {

},
// Declaration style for newer browsers
doSomethingElse ( ) {

}
// extend bar.foo here
};
// Freeze the namespace so that
// it can’t be modified by other code
O b j e c t . f r e e z e ( barNS . f o o ) ;
} ) ( bar ) ;
 Chapter 3

Logic Guidelines [Logic]

(3)
1 Logic in a file or page should be isolated in an Immediately Invoked Function Expression (IIFE).
Code running outside of an IIFE interacts with the global object, usually the window. This
means that any other code running on the page can modify any variables declared outside of a
closure created by an IIFE.
[ Note: This is not required in Lightning controllers, helpers, or renders. These run in isolated
closures by default. — end note ]

Example:
( function ( ) {
’use strict’ ;
// code goes here
})();
2 Logic should run in Strict mode to reduce the chance of developer errors.
Strict mode can prevent a lot of common mistakes in ECMAScript such as:
• Inadvertently assigning to the global object.
• Referencing an undeclared variable.
• Prevents silent unexpected failures.
[ Note: Lightning controllers, helpers, and renders all run in Strict mode if Locker Service is
enabled. See the Lightning standards for more information. — end note ]
3 In a chain of if statements, an else shall not be used if the prior if returns from the method.
4 Comparisons between two values shall use the === or ==! operators.
5 A developer should not make a comparison against null.
In most cases comparing against null is a mistake. By default JavaScript has multiple ways
of representing things that are not there. null is generally used to indicate that something was
there, or that a method failed in an expected way. As such, when checking to see if a value
exists, use the falsy check instead. In most cases, only directly check against null when there
is semantic meaning to the value.
6 Assignment shall not occur within a conditional.
7 isNaN() shall be the only method of checking for NaN values.
JavaScript’s NaN is based on the IEEE 754 standard. As such NaN never compares equal to
any value. Thus NaN !== NaN will always return true, and NaN === NaN will always return
false. The isNaN function is the only safe way to check if a value compares equal to NaN.

4
8 Empty blocks shall not be used
9 A developer should avoid unnecessary casts to Boolean.

3.1 Async Await Guidelines [Logic.Await]

(3.1)
1 await shall not be used in a loop.
If a developer needs to await multiple items they should use Promise.all instead. awaiting
in a loop results in the browser making multiple calls back into the runtime that block other
processing. With Promise.all the runtime knows that all of the Promises need to have
completed prior to the continuation. This helps fully exploit the parallelism that async and
await provide.
Source: ESLint: no-await-in-loop.

Example:
// Use ES6 destructuring to get each
// result in an separate variable
const [ r e s u l t 1 , r e s u l t 2 , r e s u l t 3 ] =
a w a i t Promise . a l l ( [ promise1 , promise2 , p r o m i s e 3 ] ) ;
2 A developer shall not await a value they are returning.
awaiting a return value creates a performance hazard because it causes the runtime to pause
and resolve the awaited Promise. In an async method returning a Promise is fine as it will
replace the Promise the runtime would have generated as the return value. This allows the
method calling to choose how to await and prevents awaiting in a loop.
Source: ESLint: no-return-await.
Glossary

closure The function or lexical environment in which a variable is declared see: MDN Closures.
4

IIFE Immediately Invoked Function Expression. 4

Strict mode A restricted variant of ECMAScript that makes it harder for Developers to make
mistakes see: MDN Strict Mode. 4