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:

Good:

Use explanatory names for functions.

This goes without saying, try to explain what the function is doing in its name, it shouldn’t have the words: Func, function, handle, do, execute or any similar to those.

Bad:

Good:

Name CONSTANTS.

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

Bad:

Good:

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:

Also Bad:

Good:

Good:

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.

Commenting guidelines

First things first, you probably shouldn’t comment every method or variable you create on the codebase, if functionality is clear enough, there is no need to add additional context to it, so e.g.

Is a pretty good example of self commented code, there is probably no need to write anything else to it. It's clear the function is used to remove the letter A from an array of strings you, it returns a new arrayOfStrings without letter A.

However, there are a lot of cases where complexity can’t be simply described by convenient naming or beautiful code. In those cases, making use of comments is a good idea.

Where to comment?

If there is a function which has some complexity inherent to it, is convenient to make. a comment explaining what it does, how it does it, explaining complex regexes if there exists one, etc. The place to comment, is in the header of the function, just above it. Not in the actual function code. Avoid doing:

Trying to explain your code inside a function forces the reader to read the whole thing, to understand what is being done, and incites you as the writer of the comment to write comments to coupled with the context of the code.

Instead, try to write comments that explain, what the function does ? What parameters does it receive? and what does it return? I will do this following the JS Doc “syntax”

You will see, after just one example, its much easier to see that function and understand what it does without actually reading its code! Which is our goal here.

I recommend you follow the JS Doc syntax on functions that are too complex to read, and on which parameter variables or return values are not clear upon reading the function name or usage.