Coding Style Guide
These are the style guidelines for coding in Legesher.
You can run
npm run lintto show any style issues detected by
- End files with a newline.
- Place requires in the following order:
- Built in Node Modules (such as
- Built in Electron Modules (such as
- 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:
path.join()to concatenate filenames.
/tmpwhen you need to reference thetemporary directory.
- Using a plain
returnwhen returning explicitly at the end of a function.
The Python version we are using now is Python 2.7.
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 document. The document mentions some special types, scoped types (that automatically release their memory when going out of scope), logging mechanisms etc.
You can run
npm run lint-docsto ensure that your documentation changes are formatted correctly.
- File names should be concatenated with
file_name.js, because ingithub/atom module names are usually inthe
module-nameform. This rule only applies to
Legesher APIs uses the same capitalization scheme as Node.js:
- When the module itself is a class like
- When the module is a set of APIs, like
- When the API is a property of object, and it is complex enough to be in aseparate chapter like
- For other non-module APIs, use natural titles, like
When creating a new API, it is preferred to use getters and setters instead of jQuery's one-function style. For example,
.setText(text)are preferred to
.text([text]). There is a discussion on this.