documentation/CONTRIBUTING-CODE.md

   1 # Contributing code
   2
   3
   4 ## Localizations
   5
   6 Contribute your localization! Copy the `extension/locale/en-US` directory and go
   7 wild! Usually, it’s best to stick to the master branch.
   8
   9 Tip: If you’re translating into, for example, Swedish, run `gulp sync-locales
  10 --sv-SE?` to see how many percent is done. All lines (including line numbers)
  11 that don’t differ compared to “en-US” are also printed, letting you know what’s
  12 left to do. Substitute “sv-SE” with the locale you’re working on.
  13
  14 Also, don’t worry if you can’t get a 100% difference compared to “en-US.”
  15 Sometimes text strings are very short and will look identical in both languages.
  16 That’s completely OK.
  17
  18
  19 ## Code
  20
  21 Create a new topic branch, based on either master or develop.
  22
  23     git checkout -b my-topic-branch master
  24     # or
  25     git checkout -b my-topic-branch develop
  26
  27 Code! Try to follow these simple rules:
  28
  29 - Always use parentheses when calling functions.
  30 - Always use braces for object literals.
  31 - Always use explicit `return`s, unless the function is a one-liner.
  32 - Always use single quotes, unless you use interpolation.
  33 - Prefer interpolation over concatenation, both for strings and regexes.
  34 - Always use the following forms (not any aliases):
  35   - `true` and `false`
  36   - `==` and `!=`
  37   - `and` and `or`
  38   - `not`
  39 - Never use `++` and `--`.
  40 - Never put spaces directly inside `[]` and `{}`.
  41 - Never put spaces before or more than one space after `:` in object literals.
  42 - Never use `when ... then` in `switch`es; replace `then` with a newline.
  43 - Avoid vertical alignment of code (such as aligning `=`s).
  44 - Comment when necessary. Comments should be full sentences.
  45 - Keep lines at most 80 characters long.
  46 - Indent using two spaces.
  47 - Commit no `console.log(...)`s (but do use them when debugging).
  48
  49 See [tools.md] for how to **build,** **lint,** and **run the tests.**
  50
  51 Break up your pull request in several commits if necessary. The first line of
  52 commit messages should be a short summary. If needed, add a blank line and then
  53 a nicely formatted markdown description.
  54
  55 Finally send a pull request to same branch as you based your topic branch on
  56 (master or develop).
  57
  58 [tools.md]: tools.md