Skip to content

Latest commit

 

History

History
151 lines (115 loc) · 5.54 KB

CONTRIBUTING.md

File metadata and controls

151 lines (115 loc) · 5.54 KB
Raw

Contributing to Keymash

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

The following is a set of guidelines for contributing to this packages. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

This was modified from Atom's Contributing guidelines with some edits for my own preferences and trimming out things that will never apply to my smaller projects.

Table Of Contents

Code of Conduct

How Can I Contribute?

Styleguides

Additional Notes

Code of Conduct

Be awesome to each other. See the Code of Conduct.

How Can I Contribute?

Bugs/Suggestions/Questions?

Bugs, enhancements, and questions and comments are tracked as GitHub issues.

Simply fill in the relevant template.

Pull Requests

The process described here has several goals:

  • Maintain code quality and style

Please follow these steps to have your contribution considered:

  1. Follow all instructions in the template
  2. Follow the styleguides
  3. Submit a pull request and await triage!

Styleguides

Git Commit Messages

  • Commit messages are sentences, using the commit itself as the subject of the first sentence.
    • Use the present tense, indicative mood: ("Moves files around", not "Move..." or "Moved...")
  • Limit the first line to 72 characters or less
  • Reference issues and pull requests liberally after the first line
  • 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
    • 🐛 :bug: when fixing a bug
    • 🔥 :fire: when removing code or files
    • ✅ :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

JavaScript Styleguide

All JavaScript must adhere to JavaScript Standard Style.

  • Prefer the object spread operator ({...anotherObj}) to Object.assign()
  • Inline exports with expressions whenever possible 
    // Use this:
export default class ClassName {

}

// Instead of:
class ClassName {

}
export default ClassName
  • Place requires in the following order:
    • Built in Node Modules (such as path)
    • Built in Atom and Electron Modules (such as atom, remote)
    • Local Modules (using relative paths)
  • Place class properties in the following order:
    • Class methods and properties (methods starting with static)
    • Instance methods and properties

CoffeeScript Styleguide

  • Set parameter defaults without spaces around the equal sign
    • clear = (count=1) -> instead of clear = (count = 1) ->
  • Use spaces around operators
    • count + 1 instead of count+1
  • Use spaces after commas (unless separated by newlines)
  • Use parentheses if it improves code clarity.
  • Prefer alphabetic keywords to symbolic keywords:
    • a is b instead of a == b
  • Avoid spaces inside the curly-braces of hash literals:
    • {a: 1, b: 2} instead of { a: 1, b: 2 }
  • Include a single line of whitespace between methods.
  • Capitalize initialisms and acronyms in names, except for the first word, which should be lower-case:
    • getURI instead of getUri
    • uriToOpen instead of URIToOpen
  • Use slice() to copy an array
  • Add an explicit return when your function ends with a for/while loop and you don't want it to return a collected array.
  • Use this instead of a standalone @
    • return this instead of return @
  • Place requires in the following order:
    • Built in Node Modules (such as path)
    • Built in Atom and Electron Modules (such as atom, remote)
    • Local Modules (using relative paths)
  • Place class properties in the following order:
    • Class methods and properties (methods starting with a @)
    • Instance methods and properties

Specs Styleguide

  • Include thoughtfully-worded, well-structured Jasmine specs in the ./spec folder.
  • Treat describe as a noun or situation.
  • Treat it as a statement about state or how an operation changes state.

Example

describe 'a dog', ->
 it 'barks', ->
 # spec here
 describe 'when the dog is happy', ->
  it 'wags its tail', ->
  # spec here

Documentation Styleguide

  • Use AtomDoc.
  • Use Markdown.
  • Reference methods and classes in markdown with the custom {} notation:
    • Reference classes with {ClassName}
    • Reference instance methods with {ClassName::methodName}
    • Reference class methods with {ClassName.methodName}