Skip to main content
Long Tran
💬
0 discussions

Coding Style

I. Coding Style

1. Name

  • Using camelCase for variable, function, object eg: name, idUser, idCallcenter
  • Using PascalCase for class, component eg: User, Callcenter
  • Using UPPER_CASE for constant eg: MAX, MIN
  • Using snake_case for file name eg: user.service.ts
  • Using kebab-case for folder name eg: user-service

2. Variable

  • Using let, const instead of var eg: let name = 'Gcalls'; const age = 2023 - 2015
  • Using const for variables that do not change eg: const name = 'Gcalls';
  • Using let for variable that change eg: let age = 2023 - 2015; age = 2023 - 2017;

3. Function

  • Using arrow function instead of function declaration

    • Example:
    const fn1 = (a) => {
    return a * a;
    };

    instead of

    function fn1(a) {
    return a * a;
    }
  • Using function expression for function that use in one file

    • Example:
    const fn1 = function (a) {
    return a * a;
    };

    instead of

    function fn1(a) {
    return a * a;
    }

4. Object

  • Using an object literal instead of js new Object()

    • Example:
    const obj = {};

    instead of

    const obj = new Object();
  • Using spread operator instead of Object.assign()

    • Example:
    const obj1 = { a: 1, b: 2 };
    const obj2 = { c: 3, d: 4 };
    const obj3 = { ...obj1, ...obj2 }; // { a: 1, b: 2, c: 3, d: 4 }
  • Using rest operator instead of Object.keys()

    • Example:
    const obj = { a: 1, b: 2, c: 3 };
    const { a, ...rest } = obj; // a = 1, rest = { b: 2, c: 3 }
  • Using object destructuring instead of obj.a, obj.b

    • Example:
    const obj = { a: 1, b: 2, c: 3 };
    const { a, b, c } = obj; // a = 1, b = 2, c = 3

5. Array

  • Using array literal instead of new Array()

    • Example:
    const arr = [];

    instead of

    const arr = new Array();
  • Using spread and rest operator instead of push, concat, unshift, splice, slice

    • Example:
    const arr1 = [1, 2, 3];
    const arr2 = [4, 5, 6];
    const arr3 = [...arr1, ...arr2]; // [1, 2, 3, 4, 5, 6]
    const arr4 = [...arr1, 7, 8, 9]; // [1, 2, 3, 7, 8, 9]
    const [a, b, ...rest] = arr1; // a = 1, b = 2, rest = [3]

6. String

  • Using template string instead of string concatenation

    • Example:
    const name = "Gcalls";
    const str1 = `Hello ${name}`; // Hello Gcalls
    const str2 = `Hello ${name.toUpperCase()}`; // Hello GCALLS

7. Comparison

  • Using === instead of ==

    • Example:
    const a = 1;
    const b = "1";
    a === b; // false
    a == b; // true
  • Using !== instead of !=

    • Example:
    const a = 1;
    const b = "1";
    a !== b; // true
    a != b; // false
  • Using >, <, >=, <= instead of >=, <=, ==, !=

    • Example:
    const a = 1;
    const b = 2;
    a > b; // false
    a < b; // true
    a >= b; // false
    a <= b; // true
  • Using &&, || instead of &, |

    • Example:
    const a = 1;
    const b = 2;
    const c = 3;
    a > b && a > c; // false
    a > b || a > c; // false

8. Loop

  • Using for...of instead of for...in

    • Example:
    const arr = [1, 2, 3];
    for (const item of arr) {
    console.log(item);
    }
  • Using methods instead of a self-handler function

    • Example:
    const arr = [1, 2, 3];
    arr.forEach((item) => {
    console.log(item);
    });

    instead of

    const arr = [1, 2, 3];
    for (let i = 0; i < arr.length; i++) {
    console.log(arr[i]);
    }

9. Module

  • Using ES6 module instead of CommonJS

    • Example:
    // file1.js
    export const name = "Gcalls";
    export const age = 2023 - 2015;
    export default function (a) {
    return a * a;
    }
    // file2.js
    import fn1, { name, age } from "./file1.js";

10. Others

10.1. Formatter

  • Using Prettier for code formatter
  • Using ESLint for code linter
  • Using Husky for pre-commit hook
  • Using lint-staged for linting before commit
  • Using commitizen for commit message convention

10.2. Logging

II. How to update code

  1. For small changes ( 1 2 lines of code)

    • Can edit directly, comment right next to it or comment all, write new code
  2. For medium changes ( 1 block of code in a function, write a new function)

    • Comment on old code, write new code below, write a new comment to explain the old code and the new code, comment end of the new code block
    //fix limit
    //limit = parseInt(limit)
  3. To add a file or folder

    • Create a file or folder, and comment reason for creating the file or folder
  4. To delete a file or folder

    • Comment the reason for deleting the file or folder
  5. For update README.md

    • Comment the reason for updating README.md
  6. For update changes if already comment before

    • Comment on the reason for updating the change

III. Regulation of API

1. Success

{
"success": true,
"data": {
"id": 1,
"name": "Gcalls",
"age": 6
}
}

2. Error

  • For errors with user authentication, using HTTP status code 403 eg: the user does not permission

  • For errors with authentication, using HTTP status code 401 eg: token invalid, token expired

  • For resource not found error, use HTTP status code 404

  • For server errors, use HTTP status code 500

  • For validation error, use HTTP status code 422

  • For all error responses, use HTTP status code 400

    {
    "success": false,
    "errors": [
    {
    "field": "name",
    "message": "Name is required"
    },
    {
    "field": "age",
    "message": "Age must be a number"
    }
    ]
    }

IV. Regulation of structure

1. Folder structure


src
├──models => It\'s a part that communicate with database, like query, create, update, delete
├──configs => Contains a service config, get from `.env` file
├──routers => Contains files for handle routing. Each file is a router
├──controllers => Contains files for handle request, response
├──middlewares => Contains files for handle middleware
└──utils => Contains utility or helper functions that provide common functionality or reusable eg: formatDate, formatNumber
index.js => For start project

V. Version Control

1. Common rules

1.1. Branch naming rule

  • The branch name must be formatted as follows: [dev|doc|fix]_<PoC>_<title>

1.2. Commit rule

  • Short commit message, commit message must be written in English
  • Commit messages must follow the conventions
    • feat: A new feature
    • fix: A bug fix
    • docs: Documentation only changes
    • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
    • refactor: A code change that neither fixes a bug nor adds a feature
    • perf: A code change that improves performance
    • test: Adding missing or correcting existing tests
    • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
    • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
    • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
    • revert: Reverts a previous commit
    • wip: Work in progress

1.3. Changelog rule

This guide following Keep a Changelog

  • Changelog must be written in English

  • Keep an unreleased section at the top to track upcoming changes.

  • Example changelog

    ## [1.0.0] - 2020-01-01

    ### Added

    - Add new feature

    ### Changed

    - Change feature

    ### Fixed

    - Fix bug

VI. Flow handling ticket

Flow handling ticket