Files
rrweb/docs/development/coding-style.md
Justin Halsall 1355917e1b Chore: Add issue/pr template and general housekeeping tools and docs (#900)
* Add linting

* Add issue templates and docs

* Add root eslint config and remove tslint

* Autofix lint issues
2022-05-22 09:59:42 +08:00

2.3 KiB

Coding Style

These are the style guidelines for coding in Electron.

You can run yarn lint to show any style issues detected by tslint and eslint.

General Code

  • End files with a newline.
  • Using a plain return when returning explicitly at the end of a function.
    • Not return null, return undefined, null or undefined

Documentation

  • Write remark markdown style.

TypeScript

  • Write standard JavaScript style.
  • File names should be concatenated with - instead of _, e.g. file-name.js rather than file_name.js, because in github/atom module names are usually in the module-name form. This rule only applies to .js files.
  • Use newer ES6/ES2015 syntax where appropriate
    • const for requires and other constants. If the value is a primitive, use uppercase naming (eg const NUMBER_OF_RETRIES = 5).
    • let for defining variables
    • Arrow functions instead of function () { }
    • Template literals instead of string concatenation using +

Naming Things

Electron APIs uses the same capitalization scheme as Node.js:

  • When the module itself is a class like BrowserWindow, use PascalCase.
  • When the module is a set of APIs, like globalShortcut, use camelCase.
  • When the API is a property of object, and it is complex enough to be in a separate chapter like win.webContents, use mixedCase.
  • For other non-module APIs, use natural titles, like <webview> Tag or Process Object.

When creating a new API, it is preferred to use getters and setters instead of jQuery's one-function style. For example, .getText() and .setText(text) are preferred to .text([text]). There is a discussion on this.