Skip to content

Latest commit

 

History

History
86 lines (70 loc) · 4.28 KB

CONTRIBUTING.md

File metadata and controls

86 lines (70 loc) · 4.28 KB

Contributing to editor-framework

First off, thanks for taking the time to contribute!

The following is a set of guidelines for contributing to editor-framework and its packages.

Coding Style Guide

General

  • editor-framework recommend a tab size of 2 spaces.
  • use dash naming rules for files and folders ( e.g. foo-bar )
  • use camelCase naming rules for module methods and properties ( e.g. fooBar )
  • use CamelCase naming rules for modules ( e.g. FooBar )
  • use upper-case for the first character of required module ( e.g. var Foo = require('foo') )
  • use _ prefix for private method or variables ( e.g. var _foobar = 'FooBar' )

Editor, Plugins and Editor-Framework

  • Recommend Ipc message in the form of module-name:ipc-channel-name ( e.g. foo-bar:say-hello)
  • Recommend DOM event in Polymer in the form of _onMyEvent ( e.g. <foobar on-click="_onClick" />)

Submitting Issues

  • Include the version of editor-framework you are using and the OS.
  • Include screenshots and animated GIFs whenever possible; they are immensely helpful.
  • Check the dev tools (alt-cmd-i) for errors to include. If the dev tools are open before the error is triggered, a full stack trace for the error will be logged. If you can reproduce the error, use this approach to get the full stack trace and include it in the issue.
  • On Mac, check Console.app for stack traces to include if reporting a crash.
  • Perform a cursory search to see if a similar issue has already been submitted.
  • Please setup a profile picture to make yourself recognizable and so we can all get to know each other better.

Pull Requests

  • Include screenshots and animated GIFs in your pull request whenever possible.
  • JavaScript, and CSS styleguides.
  • Include thoughtfully-worded, well-structured Mocha specs. See Editor-Framework tests for example.
  • Document new code with comments in source code based on the Firedoc User Guide
  • End files with a newline.
  • Place requires in the following order:
    • Built in Node Modules (such as path)
    • Built in editor-framework and Electron Modules (such as fire-fs, shell)
    • 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 require('atom').fs.getHomeDirectory() to get the home directory.
    • 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

Git Commit Messages

  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Limit the first line to 72 characters or less
  • Reference issues and pull requests liberally
  • Consider starting the commit message with an applicable emoji:
    • 🎨 :art: when improving the format/structure of the code
    • 🐎 :racehorse: when improving performance
    • 🚱 :non-potable_water: when plugging memory leaks
    • 📝 :memo: when writing docs
    • 🐧 :penguin: when fixing something on Linux
    • 🍎 :apple: when fixing something on Mac OS
    • 🏁 :checkered_flag: when fixing something on Windows
    • 🐛 :bug: when fixing a bug
    • 🔥 :fire: when removing code or files
    • 💚 :green_heart: when fixing the CI build
    • :white_check_mark: when adding tests
    • 🔒 :lock: when dealing with security
    • ⬆️ :arrow_up: when upgrading dependencies
    • ⬇️ :arrow_down: when downgrading dependencies
    • 👕 :shirt: when removing linter warnings

Documentation Styleguide