Skip to content

Latest commit

 

History

History
147 lines (102 loc) · 5.02 KB

README.md

File metadata and controls

147 lines (102 loc) · 5.02 KB
Raw

JavaScript Guidelines

In this document

General Guidelines

In order to improve the clarity, quality, and development time it is worth considering the following principles whenever possible:

Style Guide

  • Airbnb JavaScript Style Guide is partially being followed in our code base.

  • Most styling issues will be caught by ESLint, so before pushing your changes remember to run grunt eslint to catch and fix any issues that it finds.

  • Check below for the rules that are not caught by ESLint but should be followed.

Naming Conventions

Variables: Variables should be lowercase words separated by _.

const field_name = '...';

Functions: Functions should be camelCase. This is to easily distinguish between variables and functions.

const myFunction = () => { ... };

Modules: Module names and classes should be PascalCase.

const MyModule = (() => { ... })();

jQuery variables: jQuery variables should have a $ in the beginning to mark them.

const $test = $('#test');

JavaScript elements: JavaScript elements start with el_ for a similar effect.

const el_test = document.getElementById('test');

Boolean: Those variables which store a boolean value, should start with is_, has_, ...

const is_updated = true;
const has_crypto = false;

Form elements: Consider prefixes for form elements to make it more obvious what type of field they are, such as:

const fields = {
  txt_name: { id: '#txt_name' },
  chk_tnc: { id: '#chk_tnc' },
  ddl_agents: { id: '#ddl_agents' },
};

Commenting

Explanations: Feel free to add comments to explain any code that is confusing.

To do: Use TODO: ... comments anywhere that needs consideration or attention in the future.

API requests: Comments should be added to highlight logic that is hardcoded in the front-end and should move to API:

  • For changes that can be done in API V3, use the comment

    // API_V3: [description of what needs to be moved to API]

  • For changes that should be done in API V4, use the comment

    // API_V4: [description of what needs to be moved to API]

Import Rules

Require: Use require instead of import to stay consistent with the current codebase. We could change it to import when switching to React.

Align by equal: Assignments are generally aligned by = for readability purposes.

const moment = require('moment'); // moment is an npm package
const CookieStorage = require('./storage').CookieStorage; // our own function
const applyToAllElements = require('./utility').applyToAllElements; // our own function
const createElement = require('./utility').createElement; // our own function
require('../../_common/lib/polyfills/array.includes'); // polyfill from lib folder
require('../../_common/lib/polyfills/string.includes'); // polyfill from lib folder

Alphabetical ordering: The order is important; it should be sorted alphabetically according to the path:

  • moment comes first as it's not a relative path.
  • s is before u so ./storage comes before ./utility.
  • Both applyToAllElements and createElement are from the same file, but a is before c
  • Unassigned require goes to the end

Combining require: When there are many functions being imported from the same file, consider combining it into one import line.

const Utility = require('./utility');

...

Utility.handleHash();
Utility.createElement('div');
...