Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

This document is intended to be followed when reviewing Pull Requests (PR) on both back and frontend code.

Its mostly inspired by the current style guides for Airbnb and Clean Code JS.

Why is this necessary ?

Having a style guide we can all agree upon achieves two things, it makes our code predictable and readable for everyone currently involved in the app, which makes getting into the code for a task, bug or whatever feature we are working on the app a simple seamless task, you shouldn’t spend more than one minute trying to understand what a variable is, what a function is doing, or what a file is for.

Another thing you accomplish by making code mostly consistent throughout the whole app, is that contribution to the project becomes an easy task as well, just following the style guide and providing the functionality needed is enough to complete a particular requirement.

So, faster development and faster new team members integration.

When and where would I apply these rules?

Hopefully after some getting used to, all the time, however, we will have a pre-commit-hook so you get reminded every time you commit, to check for these rules on your particular commit. Also, your potential PR’s will be reviewed based on this style guide.

These rules apply both to the backend app located under packages/api and the frontend app located under packages/webapp .

General Formatting

General formatting rules you can probably configure in your editor so it auto formats for you.

  • 2 spaces indentation.

  • Maximum line length of 100 characters.

  • Single Quotes.

  • 1 space before leading brace (see 19.2).

  • 1 space before the opening parenthesis in control statements (if, while etc.). No space between the argument list and the function name in function calls and declarations ( see 19.3).

  • Spaces Between operators (see 19.5).

  • No spaces between parenthesis, or brackets (read 19.10, 19.11).

  • Spaces between curly braces (read 19.12).

  • No spaces before commas, and 1 space after a comma.

Naming Conventions

We are following the following naming conventions:

  • UPPERCASE NAMES FOR CONSTANTS

  • Upper Camel Case Names For Classes

  • loweCamelCase for everything else.

Use meaningful and pronounceable variable names

Bad:

const yyyymmdstr = moment().format("YYYY/MM/DD");

Good:

const currentDate = moment().format("YYYY/MM/DD");

Name CONSTANTS.

Random numbers, strings or booleans in our code that actually hold meaning makes our code hard to understand. (refer to)

Bad: 

delay(192192010241) // What is that number?

Good: 

const LONG_RANDOM_NUMBER = 192192010241;
delay(LONG_RANDOM_NUMBER);

Don't add unneeded context

If you are declaring an array, you don’t need to append the word list to it, objects plural form works better. If you created a class, don’t provide every one of its properties with the name of the class (refer to)

Bad:

class Animal {
  constructor(animalType, animalColor, animalName){}
}

Also Bad:

const animalList = ['Frog', 'Cat', 'Mouse'];

Good: 

class Animal {
  constructor(type, color, name){}
}

Good: 

const animals =['Frog', 'Cat', 'Mouse'];

Encapsulate conditionals (refer to)

Avoid negative conditionals (refer to)

Follow Solid Principles (refer to)

Do not leave commented code on the codebase

This is quite simple to understand, if you are replacing a piece of code, feel free to delete it entirely, remember, we are using version control, if you later find out, you need that code, just checkout to the previous commit and get it back.

  • No labels