documentation/CONTRIBUTING-CODE.md

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