2.3 KiB
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 eslint.
General Code
- End files with a newline.
- Using a plain
returnwhen returning explicitly at the end of a function.- Not
return null,return undefined,nullorundefined
- Not
Documentation
- Write remark markdown style.
TypeScript
- Write standard JavaScript style.
- File names should be concatenated with
-instead of_, e.g.file-name.jsrather thanfile_name.js, because in github/atom module names are usually in themodule-nameform. This rule only applies to.jsfiles. - Use newer ES6/ES2015 syntax where appropriate
constfor requires and other constants. If the value is a primitive, use uppercase naming (egconst NUMBER_OF_RETRIES = 5).letfor 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, usePascalCase. - When the module is a set of APIs, like
globalShortcut, usecamelCase. - When the API is a property of object, and it is complex enough to be in a
separate chapter like
win.webContents, usemixedCase. - For other non-module APIs, use natural titles, like
<webview> TagorProcess 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.