Coding convention

By Backend

Think about the design of the functions before writing them

Break your functions

Function should do only one thing and very well

Take a moment to name the variables well

Naming Convention

Repositories

To find one

To find many

To update one

To update many

Export them as:

When you import repositories, name them in PascalCase:

Controllers

Must end with ‘Ctrl’ and camelCase

Functions

Since the function is supposed to do one thing only, names could be [”doThis”, ”doThat”, “getUserData”]

Make sure functions do what they say. Not more or less.

Variables

First of all, take a few minutes if you cant come up with good name

A variable that contains an object must be named as its entity name:

“task”, “member” etc

If the variable contains id of an entity then it will be named as:

“taskId”, “memberId” etc

camelCase for naming variables inside any block

Coding

Repositories

No more of these → updateMemberById, updateTask, etc.

Read repository section of “Naming Convention”

Repositories should not have any logic

Use query builder(helpers/queryBuilder.js) to build necessary queries, instead of creating multiple queries and bringing logic into them

They should be like this, plain and simple: NOTICE THE STRUCTURE

Function

Think about the design of the functions before writing them.

Break the functions as much as possible.

Function should do only one thing and very well.

Single Level Abstraction

⁠

https://medium.com/@outfunnel/the-single-level-of-abstraction-principle-52b5d56ef54b⁠

⁠

Single Responsibility Principle and SLA^

⁠

https://tech.jotform.com/srp-and-slap-keys-to-maintainable-and-readable-code-d11396816508⁠

⁠

Try to fit the function in one page by breaking it and making functions for each unit of work. If your function is long see if you can name any block of code by something or not. Then make a function with that name

If the parameter count is over 2/3 then pass them as objects

Try to avoid nested if else by returning early using inverted logic:

Services

Services will call Repositories for data access and manipulations

Try to make services atomic. Of course there will be one big orchestrator service that will use lots of service to do its work.

A service is responsible for implementing the business logic and application specific functionality.

It often acts as an intermediary between the controller and the data access layer (repository).

Try to look for related work and group them into one service.

Controller

Remember controller is the one who “controls” things. It will take in request and send response using the services.

Logging

Put logging before each action atleast, doing it after the action might be useful too.

Use our logger util from “logger.js” file in “helpers” folder

Error Handling

coming

Utilities

If you have large/complex match query then put it inside helpers/queryBuilder.js folder to encapsulate the logic for maintainability and readability.

All the associated utilities will go in one file (helpers.js folder) . Example:

Utilities that work with array will go to array.js

To send notification, modify the code as below:

Performance

Promise.all: Use promise.all() properly to run tasks in parallel.

Git flow

Label

Put “Review Required” label when you create a PR

Once everybody has reviewed the code the label will be “Ready”

local → dev

dev

feature

⁠
None
⁠
⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

By Backend

Naming Convention

Repositories

Controllers

Functions

Variables

Coding

Repositories

Function

Services

Controller

Logging

Error Handling

Utilities

Performance

Git flow

⁠None⁠⁠

⁠
None
⁠
⁠