2015-08-31 05:31:14 +00:00
|
|
|
# Coding Style
|
|
|
|
|
|
|
|
These are the style guidelines for coding in Electron.
|
2013-09-09 07:35:57 +00:00
|
|
|
|
2016-03-07 21:58:49 +00:00
|
|
|
You can run `npm run lint` to show any style issues detected by `cpplint` and
|
|
|
|
`eslint`.
|
2016-03-07 17:46:05 +00:00
|
|
|
|
2018-02-12 14:09:38 +00:00
|
|
|
## General Code
|
|
|
|
|
|
|
|
* End files with a newline.
|
|
|
|
* Place requires in the following order:
|
|
|
|
* Built in Node Modules (such as `path`)
|
|
|
|
* Built in Electron Modules (such as `ipc`, `app`)
|
|
|
|
* Local Modules (using relative paths)
|
|
|
|
* Place class properties in the following order:
|
|
|
|
* Class methods and properties (methods starting with a `@`)
|
|
|
|
* Instance methods and properties
|
|
|
|
* Avoid platform-dependent code:
|
|
|
|
* Use `path.join()` to concatenate filenames.
|
|
|
|
* Use `os.tmpdir()` rather than `/tmp` when you need to reference the
|
|
|
|
temporary directory.
|
|
|
|
* Using a plain `return` when returning explicitly at the end of a function.
|
2018-05-12 08:12:28 +00:00
|
|
|
* Not `return null`, `return undefined`, `null` or `undefined`
|
2018-02-12 14:09:38 +00:00
|
|
|
|
2013-08-14 22:43:35 +00:00
|
|
|
## C++ and Python
|
|
|
|
|
2024-05-29 09:41:15 +00:00
|
|
|
For C++ and Python, we follow Chromium's
|
|
|
|
[Coding Style](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/styleguide/styleguide.md).
|
2021-10-27 01:18:38 +00:00
|
|
|
There is also a script `script/cpplint.py` to check whether all files conform.
|
2013-08-14 22:43:35 +00:00
|
|
|
|
2022-04-11 23:05:21 +00:00
|
|
|
The Python version we are using now is Python 3.9.
|
2013-08-14 22:43:35 +00:00
|
|
|
|
2015-08-31 05:31:14 +00:00
|
|
|
The C++ code uses a lot of Chromium's abstractions and types, so it's
|
|
|
|
recommended to get acquainted with them. A good place to start is
|
|
|
|
Chromium's [Important Abstractions and Data Structures](https://www.chromium.org/developers/coding-style/important-abstractions-and-data-structures)
|
|
|
|
document. The document mentions some special types, scoped types (that
|
|
|
|
automatically release their memory when going out of scope), logging mechanisms
|
|
|
|
etc.
|
2015-08-21 19:23:49 +00:00
|
|
|
|
2018-02-12 14:09:38 +00:00
|
|
|
## Documentation
|
|
|
|
|
2018-07-20 17:58:19 +00:00
|
|
|
* Write [remark](https://github.com/remarkjs/remark) markdown style.
|
2018-02-12 14:09:38 +00:00
|
|
|
|
|
|
|
You can run `npm run lint-docs` to ensure that your documentation changes are
|
|
|
|
formatted correctly.
|
|
|
|
|
2016-03-07 17:43:04 +00:00
|
|
|
## JavaScript
|
2013-08-14 22:43:35 +00:00
|
|
|
|
2020-11-02 09:58:14 +00:00
|
|
|
* Write [standard](https://www.npmjs.com/package/standard) JavaScript style.
|
2013-08-29 14:37:51 +00:00
|
|
|
* File names should be concatenated with `-` instead of `_`, e.g.
|
2016-03-07 17:43:04 +00:00
|
|
|
`file-name.js` rather than `file_name.js`, because in
|
2023-04-16 04:20:59 +00:00
|
|
|
[atom/atom](https://github.com/atom/atom) module names are usually in
|
2016-03-07 17:43:04 +00:00
|
|
|
the `module-name` form. This rule only applies to `.js` files.
|
|
|
|
* Use newer ES6/ES2015 syntax where appropriate
|
|
|
|
* [`const`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const)
|
2019-11-04 18:25:43 +00:00
|
|
|
for requires and other constants. If the value is a primitive, use uppercase naming (eg `const NUMBER_OF_RETRIES = 5`).
|
2016-03-07 17:43:04 +00:00
|
|
|
* [`let`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let)
|
|
|
|
for defining variables
|
|
|
|
* [Arrow functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions)
|
|
|
|
instead of `function () { }`
|
|
|
|
* [Template literals](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals)
|
|
|
|
instead of string concatenation using `+`
|
2013-08-14 22:43:35 +00:00
|
|
|
|
2016-04-07 16:40:31 +00:00
|
|
|
## Naming Things
|
2013-08-14 22:43:35 +00:00
|
|
|
|
2016-04-07 16:40:31 +00:00
|
|
|
Electron APIs uses the same capitalization scheme as Node.js:
|
|
|
|
|
2020-11-23 17:15:27 +00:00
|
|
|
* 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
|
2016-04-22 13:53:26 +00:00
|
|
|
separate chapter like `win.webContents`, use `mixedCase`.
|
2020-11-23 17:15:27 +00:00
|
|
|
* For other non-module APIs, use natural titles, like `<webview> Tag` or
|
2016-04-22 13:53:26 +00:00
|
|
|
`Process Object`.
|
2016-04-07 16:40:31 +00:00
|
|
|
|
|
|
|
When creating a new API, it is preferred to use getters and setters instead of
|
2015-08-31 05:31:14 +00:00
|
|
|
jQuery's one-function style. For example, `.getText()` and `.setText(text)`
|
2013-08-29 14:37:51 +00:00
|
|
|
are preferred to `.text([text])`. There is a
|
2016-03-31 23:49:59 +00:00
|
|
|
[discussion](https://github.com/electron/electron/issues/46) on this.
|