Skip to content

Latest commit

 

History

History
43 lines (32 loc) · 1.75 KB

STYLEGUIDE.md

File metadata and controls

43 lines (32 loc) · 1.75 KB
Raw

Style Guide

Here are the style rules to follow:

#1 Be consistent with the rest of the codebase

This is the number one rule and should help determine what to do in most cases.

#2 Respect Prettier and Linter rules

We use a linter and prettier to automatically help you make style guide decisions easy.

#3 File Name

Generally file names are PascalCase if they are components or classes, and camelCase otherwise. Filenames' extension must be .tsx for component files and .ts otherwise.

#4 Respect Google JavaScript style guide

The style guide accessible here should be respected. However, if a rule is not consistent with the rest of the codebase, rule #1 takes precedence. Same thing goes with any of the above rules taking precedence over this rule.

#5 Follow these grammar rules

  • Functions descriptions have to start with a verb using the third person of the singular.
    • _Ex: /\*\* Tests the validity of the input. _/*
  • Inline comments within procedures should always use the imperative.
    • Ex: // Check whether the value is true.
  • Acronyms have to be uppercased in comments.
    • Ex: // IP, DOM, CORS, URL...
    • Exception: Identity Provider = IdP
  • Acronyms have to be capitalized (but not uppercased) in variable names.
    • Ex: redirectUrl(), signInIdp()
  • Never use login/log in in comments. Use “sign-in” if it’s a noun, “sign in” if it’s a verb. The same goes for the variable name. Never use login; always use signIn.
    • Ex: // The sign-in method.
    • Ex: // Signs in the user.
  • Always start an inline comment with a capital (unless referring to the name of a variable/function), and end it with a period.
    • Ex: // This is a valid inline comment.