Coding Guidelines

Coding Guidelines For ReactJS

This document describes the coding guidelines for the application. Please follow these guidelines when contributing to the project.

General

Keep the code clean and readable. Use the following guidelines to achieve this.

Naming

Use descriptive names for variables, methods, classes, etc. Avoid abbreviations and single letter names. Use PascalCase for class names and camelCase for method and variable names. Use UPPER_CASE for constants. Use descriptive names for namespaces. Use descriptive names for files and folders. Use descriptive names for tests. Use descriptive names for branches. Use descriptive names for commits.

Indentation

Use 4 spaces for indentation. Do not use tabs.

Braces

Use braces for all control structures. Do not use braces for single line statements.

Comments

Provide comments for all public methods and classes. Use JSDoc style comments. Use single line comments for inline comments. Use multi-line comments for block comments.

Whitespace

Use a single blank line to separate members of a class. Use a single blank line to separate statements within a method. Use a single blank line to separate logical sections within a method. Use a single blank line to separate logical sections within a file. Use a single blank line to separate logical sections within a test. Use a single blank line to separate logical sections within a commit.

Line Length

Limit lines to 120 characters. Use line breaks to break up long lines.

Semicolons

Use semicolons at the end of each statement.

Quotes

Use single quotes for strings. Use double quotes for JSX attributes.

Parentheses

Use parentheses for all control structures. Do not use parentheses for single line statements.

Spacing

Use a single space after keywords, before and after operators, and after commas. Do not use spaces around parentheses. Do not use spaces around brackets. Do not use spaces around braces. Do not use spaces around angle brackets. Do not use spaces around dots. Do not use spaces around colons. Do not use spaces around semicolons. Do not use spaces around equals signs. Do not use spaces around exclamation marks. Do not use spaces around question marks. Do not use spaces around at signs. Do not use spaces around hash signs. Do not use spaces around ampersands. Do not use spaces around pipes. Do not use spaces around plus signs. Do not use spaces around minus signs. Do not use spaces around asterisks. Do not use spaces around forward slashes. Do not use spaces around back slashes. Do not use spaces around percent signs. Do not use spaces around tilde signs. Do not use spaces around caret signs. Do not use spaces around underscore signs. Do not use spaces around dollar signs. Do not use spaces around back ticks.

ReactJS

Use the following guidelines when writing ReactJS code.

Components

Use functional components over class components. Use arrow functions over function declarations. Use hooks over class methods. Use hooks over HOCs. Use hooks over render props. Use hooks over class components. Use hooks over functional components. Use hooks over class methods. Use hooks over HOCs. Use hooks over render props.

Redux

Use the following guidelines when writing Redux code.

Actions

Use the following code to create actions.

export const actionName = (payload) => ({
  type: ACTION_NAME,
  payload,
});

Services

Use the following code to create services. Services should be used to make API calls.

  • All service names should end with the word "Service", e.g. "userService".
  • All service methods should be asynchronous.
  • All service methods should return a promise.
  • All service methods should return a promise that resolves to the response data. - All service methods should return a promise that rejects to the error response data.
export async function getUserService({ userId }) {
  return callApi({
    uriEndPoint: leave.getLeaveStats.v1,
    pathParams: { userId },
  });
}

Creating API endpoints

Use the following code to create API endpoints. API endpoints should be used to make API calls.

  • All API endpoint names should be descriptive and follow the format "resourceName.actionName.v1", -- e.g. "leave.status.get.v1". -- "leave.status.update.v1". -- "leave.status.delete.v1". -- "leave.apply.v1". -- "leave.delete.v1". -- "leave.update.v1".

Another example: Below is a list of API endpoints for a "timeEntry" resource. It offers below operations: get, create, update, delete, and list.

timeEntries: {
    list: {
      v1: {
        ...defaults.methods.GET,
        ...defaults.versions.v1,
        uri: '/time-entries',
      },
    },
    get: {
      v1: {
        ...defaults.methods.GET,
        ...defaults.versions.v1,
        uri: '/time-entries/:timeEntryId',
      },
    },
    update: {
      v1: {
        ...defaults.methods.PUT,
        ...defaults.versions.v1,
        uri: '/time-entries/:timeEntryId',
      },
    },
    delete: {
      v1: {
        ...defaults.methods.DELETE,
        ...defaults.versions.v1,
        uri: '/time-entries/:timeEntryId',
      },
    },
  },

Git Commit Messages & Branch naming conventions

Use the following guidelines when writing commit messages and branch names.

Commit Messages

Use the following format for commit messages.

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Type

Use the following types for commit messages.

  • 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 tests or correcting existing tests
  • 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)
  • chore: Other changes that don't modify src or test files
  • revert: Reverts a previous commit

Scope

Use the following scopes for commit messages.

  • core: Changes to the core application
  • components: Changes to the components
  • containers: Changes to the containers
  • actions: Changes to the actions
  • reducers: Changes to the reducers
  • services: Changes to the services
  • selectors: Changes to the selectors
  • utils: Changes to the utils
  • constants: Changes to the constants
  • types: Changes to the types
  • docs: Changes to the documentation
  • tests: Changes to the tests
  • build: Changes to the build system
  • ci: Changes to the CI system
  • chore: Other changes

Branch Names

Use the following format for branch names.

<type>/<scope>/<subject>

Example branch names.

  • feat/core/add-new-feature
  • fix/components/fix-bug
  • docs/readme/update-readme
  • style/components/update-style
  • refactor/components/refactor-component
  • perf/components/improve-performance
  • test/components/add-tests
  • build/components/update-build-system
  • ci/components/update-ci-system
  • chore/components

Type

Use the following types for branch names.

  • 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 tests or correcting existing tests
  • 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)
  • chore: Other changes that don't modify src or test files
  • revert: Reverts a previous commit

Scope

Use the following scopes for branch names.

  • core: Changes to the core application
  • components: Changes to the components
  • containers: Changes to the containers
  • actions: Changes to the actions
  • reducers: Changes to the reducers
  • services: Changes to the services
  • selectors: Changes to the selectors
  • utils: Changes to the utils
  • constants: Changes to the constants
  • types: Changes to the types
  • docs: Changes to the documentation
  • tests: Changes to the tests
Code of ConductContributing