Skip to content

Rules and Settings

Jump to bottom
Yehor edited this page Nov 24, 2023 · 1 revision

Prettier settings for the project

To configure the Prettier plugin in Visual Studio Code and ensure consistent code formatting across team, follow these steps

  1. Install the Prettier plugin

  2. Add .prettierrc file in the root directory of project

  3. The file should look like this:

    {
    "trailingComma": "es5",
    "tabWidth": 2,
    "useTabs": false,
    "singleQuote": false,
    "semi": true
}

Rules for naming

Conventions and rules for naming variables, functions, classes, files, and other elements in your code.
They help improve code readability, understandability, and maintainability, and provide consistency within a project and among developers.

Rules for naming functions

Use verbs:
Name functions using verbs to describe the action they perform. For example, getUser, createOrder, updateProduct.

Use nouns:
Use nouns for functions that return objects or data, getUserInfo, getProductList.

Use camelCase:
According to the standard, JavaScript uses camelCase notation, where the first word begins with a lowercase letter and each subsequent word begins with a capital letter. For example, getUserById, createNewOrder.

Rules for naming components

Use PascalCas:
Component names should start with a capital letter, and each word in the component name should also start with a capital letter. For example: MyComponent, UserProfile, HeaderMenu.

Clear and descriptive name:
The component name should clearly reflect its purpose and functionality. This will make the code easier to read and understand.

Avoid single-letter names:
Try to avoid using single-letter names like A, B, etc. unless it makes much sense and makes your code clearer.

Examples of good component naming: UserProfile, ShoppingCart, ProductList, HeaderMenu

Examples of poorly named components: Component1 (uninformative name), userprofile (UpperCamelCase not respected), menu (too generic name)

Rules for naming types and interfaces

Use PascalCase:
Type and interface names must begin with a capital letter, and each word in a type or interface name must also begin with a capital letter.

Prefixes and Suffixes:
It is useful to add prefixes or suffixes to type or interface names to indicate their data type or purpose. For example, IUser for the user interface or UserType for the user data type.

Examples of good naming for types and interfaces: UserType(for types), IUser (for interfaces)

Examples of poorly named types and interfaces: U (too short and uninformative), string (uninformative and conflicts with the built-in data type), userDataType (UpperCamelCase not respected)

Rules for naming styles

The project will use the BEM methodology

When using the BEM (Block-Element-Modifier) methodology for CSS and SCSS, following certain class naming conventions is important to ensure your code is structured and maintainable.

Here are the basic rules for class names in SCSS in the BEM methodology:

Blocks: names represent a root element that can contain other elements and modifiers. Block names are written in lowercase and separated by hyphens.
For example: button, header, menu.

Elements: Elements represent nested parts of a block and are formatted as a block__element. Element names are also written in lowercase and separated by two underscores.
For example: button__label, menu__item, header__logo.

Modifiers: Modifiers change the style or behavior of a block or element and are styled as block_modifier or block_element_modifier. Modifier names are written in lowercase and separated by a single underscore.
For example: button_primary, menu__item_disabled, header__logo_large.

Exception: States: Sometimes you can use element states instead of modifiers. States usually look like block_is-state. For example: button_is-active, menu_is-open.

Rules for naming .env variables

Use capital letters:
All characters in .env variables must be written in capital letters for clarity and ease of readability.

Use underscores to separate words:
If the variable name consists of multiple words, separate them with an underscore. For example, API_KEY

Uniqueness and Clarity:
Provide unique and descriptive variable names to make it easier to understand their purpose.

Example:

API_KEY=your-api-key
DB_HOST=localhost
SECRET_TOKEN=your-secret-token
DEBUG_MODE=true

Rules for working with branches

Use git flow methodology in project
The project will have 2 main branches, main and develop (they are described below)
You need to use your issue key (you can find it in your Jira issue), in this project issue key will start from GLF-

Main
This is the master branch that contains the stable and released version of the application or project.
This branch only stores tested and release-ready versions of your code.
Used to demonstrate the production version of the application.

Develop
This is a development branch where all changes and new features that are developed by the team are collected.
This branch may contain unfinished and experimental features.
Used to integrate and test new changes before they are transferred to main.

How to work with branches and Jira

You need to use your issue key instead of JRA-123

  1. Create a new branch and switch to it: git checkout -b JRA-123-<new-feature>
  2. Add all changes to index: git add .
  3. Make a commit describing your changes: git commit -m "JRA-123 <commit message>"
  4. Push commits to your GitHub branch: git push origin JRA-123-<new-feature>
  5. Switch back to the develop branch: git checkout develop
  6. Get the latest changes from a remote repository: git pull origin develop

How to merge branches

  1. Switch to the target branch (e.g. develop): git checkout develop
  2. Create pull request and wait for code review
  3. Merge changes from another branch (e.g. JRA-123-new-feature): git merge JRA-123-new-feature

Clone this wiki locally