Skip to content
This repository has been archived by the owner on May 2, 2022. It is now read-only.

Coding Standards

Martin Senécal edited this page Feb 21, 2022 · 5 revisions

Git Guideline:

Branches Guideline:

Naming Convention

Bug -> BUG-ID

Story -> STORY-ID

DevOps -> OPS-ID

ID will be the ID of the Issue

Commit Guideline

Every single commit must be linked to an issue. Commit Message: #ID - Description

General Goal

1 branch/Issue, and then delete it when it's merge in master. Avoid having more than 1 layer of branches.


Coding Guideline:

General

  • Code needs to be simple enough to be understandable, but complex enough to do something useful.
  • Code should be self-contained and easy to understand as possible.
  • Don't include unnecessary code.
  • Write your code as clearly and understandably as possible, even if it is not the most efficient way to do it.
  • Indentation: 2 Space
  • Make code responsive to some degree.
  • Use comments to comment code only when it isn't self-documenting.

HTML

  • Use HTML5 doctype.
  • Add Document language, characterset.
  • Add Viewport meta tag into
  • Use lowercase for all element names and attribute names/values, as it looks neater and means you can write markup faster
  • You should put all attribute values in double-quotes.
  • Use double quotes for HTML, not single quotes:
  • Use semantic class/ID names, and separate multiple words with hyphens. Don't use camelCase.

CSS

  • Lower case for shades and primary colors. Use "basic" colors if possible, or rgb() for more complex colors.
  • Before diving in and writing huge chunks of CSS, plan your styles carefully.
  • There are a variety of CSS writing styles you can use, but we prefer the expanded style, with the selector/opening brace, close brace, and each declaration on a separate line. Include a space between the selector(s) and the opening curly brace.
  • Where quotes can or should be included, use them, and use double-quotes.
  • Function parameters should have spaces after their separating commas, but not before.
  • Use CSS-style comments to comment code that isn't self-documenting:
  • When a rule has multiple selectors, put each selector on a new line. This makes the selector list easier to read, and can help to make code lines shorter.

Firebase

JavaScript/TypeScript

  • For variable names use lowerCamelCasing, and use concise, human-readable, semantic names where appropriate.

  • For function names use lowerCamelCasing, and use concise, human-readable, semantic names where appropriate.

  • For Class names (React and MongoDB model), use CamelCasing, and use concise, human-readable, semantic names where appropriate.

  • When defining an object class (as seen above), use UpperCamelCasing (also known as PascalCasing) for the class name, and lowerCamelCasing for the object property and method names.

  • Use Arrow Function if possible.

  • For general usage, use common ES6 features (such as arrow functions, promises, let/const, template literals, and spread syntax, async/await).

  • When declaring variables and constants, use the let and const keywords, not var.

  • Use Template Literal: ``

  • Use Expanded Syntax: For JavaScript, we use expanded syntax, with each line of JS on a new line, the opening brace of a block on the same line as its associated statement, and the closing brace on a new line.

  • We also have a few specific rules around spacing inside language features. You should include spaces between operators and operands, parameters, etc.

  • Don't include padding spaces after opening brackets or before closing brackets — (myVar), not ( myVar ).

  • All statements must end with semicolons (";"). We require them in all of our code samples even though they're technically optional in JavaScript because we feel that it leads to code that is clearer and more precise about where each statement ends.

  • Use single quotes in JavaScript, wherever single quotes are needed in syntax.

  • Use JS-style comments to comment code that isn't self-documenting: // This is a JavaScript-style comment

  • Ternary operators should be put on a single line:

  • Always use strict equality and inequality (=== and !==).

  • Use shortcuts for boolean tests — use x and !x, not x === true and x === false.

  • Control Statement: `if(iceCream) {

    alert('Woo hoo!');

}`

  • Use Template Literals: For inserting values into strings, use string literals. console.log(``Hi! I'm ${myName}!``);
  • When loops are required, feel free to choose an appropriate loop out of the available ones (for, for...of, while, etc.) Just make sure to keep the code as understandable as possible. When using for/for...of loops, make sure to define the initializer properly, with a let keyword:
  • Use literals — not constructors — for creating general objects (i.e., when classes are not involved)
  • Creation of Arrays: Use literals - not constructors.
  • If certain states of your program throw uncaught errors, they will halt execution and potentially reduce the usefulness of the example. You should therefore catch errors using a try...catch block.

Source: https://developer.mozilla.org/en-US/docs/MDN/Guidelines/Code_guidelines