Files
rrweb/docs/development/coding-style.md
Eoghan Murray 9919a943a6 yarn format - prettier improvements & add .editorconfig (#1471)
Some dev improvements:
* Add .editorconfig config file https://editorconfig.org/
* move the singleQuote spec into .editorconfig and add old .changesets/*.md to .prettierignore so that we don't incorrectly reformat new changeset files to single quote from the double quote which they can be autogenerated with in github
* .gitignore Ignore emacs chaff files
* Add `yarn format:head` a convenience command to run prettier against just those files in the head commit
* Some mention of `yarn format` in the docs
* Fix some test html closing tags; authoring mistakes, rather than deliberately malformed html — picked up by an explicit `yarn prettier --write '**/*.html'`
2026-04-01 12:00:00 +08:00

2.4 KiB

Coding Style

These have been adapted from the style guidelines for coding in Electron.

You can run yarn lint to show any style issues detected by 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
  • run yarn format to rewrite all files in the standard format
  • run yarn format:head to rewrite files from your last commit

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.