Legesher Docs
  • 🗨️What is Legesher?
  • 🎨legesher-docs
    • Getting Started
    • Keyword Table
    • Glossary
    • Documentation Style Guide
    • Coding Style Guide
  • 💡Legesher
    • The Why
    • The Breakdown
    • The Roadmap
  • 🔄Legesher-translations
    • Translation Guide
    • Translation Conventions
  • 🌴tree-sitter-legesher-python
    • Tree Sitter Guide
  • 🗣️legesher-python
    • Code Editor Support Guide
  • ⚖️ The Official Things
    • Governance
    • Code of Conduct
    • Open Source License
    • Contributing Guidelines
  • 📨ORGANIZATIONAL
    • Weekly Updates
    • Changelog
Powered by GitBook
On this page
  • General Code
  • C++ and Python
  • Documentation
  • JavaScript
  • Naming Convention

Was this helpful?

  1. legesher-docs

Coding Style Guide

These are the style guidelines for coding in Legesher.

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

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.

    • Not return null, return undefined, null or undefined

C++ and Python

The Python version we are using now is Python 2.7.

Documentation

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

JavaScript

  • File names should be concatenated with - instead of _, e.g.

    file-name.js rather than file_name.js, because in

    the module-name form. This rule only applies to .js files.

  • Use newer ES6/ES2015 syntax where appropriate

    • for requires and other constants

    • for defining variables

    • instead of function () { }

    • instead of string concatenation using +

Naming Convention

Legesher 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.

PreviousDocumentation Style GuideNextThe Why

Last updated 1 year ago

Was this helpful?

For C++ and Python, we follow Chromium's . You can use to format the C++ code automatically. There is also a script script/cpplint.py to check whether all files conform.

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 document. The document mentions some special types, scoped types (that automatically release their memory when going out of scope), logging mechanisms etc.

Write markdown style.

Write JavaScript style.

module names are usually in

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 on this.

🎨
Coding Style
clang-format
Important Abstractions and Data Structures
remark
standard
github/atom
const
let
Arrow functions
Template literals
discussion