JavaScript coding style - Talend/ui GitHub Wiki

JavaScript coding style

There are two way to check your coding style and have your contribution merged.

  • ESLINT your code change shouldn't add any new warning/error
  • Peers reviews

Naming

Variables

In general, a variable name should indicate in a clear and short word (or group of words) what it contains. This implies to be readable and understandable in correct english the data without necessarily reading all the code.

Bad

// this is not explicit enough. Code below using d var won't be that understandable.
const d = [dataset1, dataset2];

Good

const datasets = [dataset1, dataset2];

You will have cases where you need to have multiple variables containing the same type of elements. Depending on the case, add a qualifier or a context to the main word.

Bad

// this is not good english
const datasetsFiltered = [dataset3, dataset6];

// this one neither, the main word is the context
const datasetsMyPicker = [dataset3, dataset6];

Good

// this is english readable
const filteredDatasets = [dataset3, dataset6];

// the main word is datasets with a context before
const myPickerDatasets = [dataset3, dataset6];

Functions

In general, the function should indicate what it does. It should be short if possible, beginning with a non-conjugated verb and followed by a qualifying phrase or word.

Bad

// this is not precise enough, we don't need to look at the implementation to know how it is filtered/transformed
function filter(datasets) {}
function transform(datasets) {}

// the verb is conjugated which doesn't indicate an action
function filteredByName(datasets) {}

Good

function filterByName(datasets) {}
function setModificationDate(datasets) {}

But the wording can vary depending on the usage.

Callback functions

Component or function callbacks must begin with on followed by the non-conjugated verb.

Bad

<MyComponent submit={() => {}} />

Good

<MyComponent onSubmit={() => {}} />

Predicate functions

The goal of the predicate naming is to make the usage code more english readable.

Bad

const checkDatasetIsDraft = dataset => {}

// this is bad because the usage is not readable
if (checkDatasetIsDraft(dataset)) {}

const filteredDatasets = datasets.filter(checkDatasetIsDraft);

Good

const isDraft = dataset => {}

// those are readable
if (isDraft(dataset)) {}

const filteredDatasets = datasets.filter(isDraft);

Function declaration

Lambda aka Arrow function

Rule Avoid lambda when

  • it is complex
  • it is affected to a variable and used in several places

Why

  • It doesn't increase readability
  • If an error happen inside, the function name will not appear on the error stacktrace.

KO

const total = (x, y) => {
    return x + y;
};

OK

function sum(x, y) {
    return x + y;
}
numbers.map((x) => x * 2);

Pure function

Rule Avoid as much as possible non-pure function.

Why It's harder to test, and less predictable in it's computation result.

Ternary operation

Rule Avoid using ternary expression if it needs to fit on more than one line

Why Ternary is less human readable than if statement. When too long, it becomes really hard to read.

KO

const reduction = isInDatabase() || isCustomerBirthday() && hasMoreThan18() ? getAdultReduction() * 5 : getBaseReduction();

OK

const reduction = isNewCustomer() ? 10 : 0;
⚠️ **GitHub.com Fallback** ⚠️