Coding Style

    You can run to show any style issues detected by cpplint and eslint.

    • 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)
    • 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.
      • Not return null, , null or undefined

    The Python version we are using now is Python 3.9.

    • Write markdown style.

    You can run npm run lint-docs to ensure that your documentation changes are formatted correctly.

    • File names should be concatenated with - instead of _, e.g. file-name.js rather than file_name.js, because in 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).
      • for defining variables
      • Arrow functions instead of
      • instead of string concatenation using +
    • 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.

    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 . There is a on this.