pulsar/CONTRIBUTING.md

# :rotating_light: Contributing to Atom :rotating_light:


## Issues
  * Include screenshots and animated GIFs whenever possible, they are immensely
    helpful
  * Include the behavior you expected to happen and other places you've seen
    that behavior such as Emacs, vi, Xcode, etc.
  * Check the Console app for stack traces to include if reporting a crash
  * Check the Dev tools (`alt-cmd-i`) for errors and stack traces to include

## Code
  * Follow the [JavaScript](https://github.com/styleguide/javascript),
    [CSS](https://github.com/styleguide/css),
    and [Objective-C](https://github.com/github/objective-c-conventions)
    styleguides
  * Include thoughtfully worded [Jasmine](http://pivotal.github.com/jasmine/)
    specs
  * Add 3rd-party packages as a `package.json` dependency
  * Commit messages are in the present tense
  * Commit messages that improve the format of the code start with :lipstick:
  * Commit messages that improve the performance start with :racehorse:
  * Commit messages that remove memory leaks start with :non-potable_water:
  * Commit messages that improve documentation start with :memo:
  * Files end with a newline
  * Class variables and methods should be in the following order:
    * Class variables (variables starting with a `@`)
    * Class methods (methods starting with a `@`)
    * Instance variables
    * Instance methods
  * Be ware of platform differences
    * The home directory is `process.env.USERPROFILE` on Windows, while on OS X
      and Linux it's `process.env.HOME`
    * Path separator is `\` on Windows, and is `/` on OS X and Linux, so use
      `path.join` to concatenate filenames.
    * Temporary directory is not `/tmp` on Windows, use `os.tmpdir()` when
      possible

## Philosophy

### Write Beautiful Code
Once you get something working, take the time to consider whether you can achieve it in a more elegant way. We're planning on open-sourcing Atom, so let's put our best foot forward.

### When in doubt, pair-up
Pairing can be an effective and fun way to pass on culture, knowledge, and taste. If you can find the time, we encourage you to work synchronously with other community members of all experience levels to help the knowledge-mulching process. It doesn't have to be all the time; a little pairing goes a long way.

### Write tests, and write them first
The test suite keeps protects our codebase from the ravages of entropy, but it only works when we have thorough coverage. Before you write implementation code, write a  failing test proving that it's needed.

### Leave the test suite better than you found it
Consider how the specs you are adding fit into the spec-file as a whole. Is this the right place for your spec? Does the spec need to be reorganized now that you're adding this extra dimension? Specs are only as useful as the next person's ability to understand them.

### Solve today's problem
Avoid adding flexibility that isn't needed *today*. Nothing is ever set in stone, and we can always go back and add flexibility later. Adding it early just means we have to pay for complexity that we might not end up using.

### Favor clarity over brevity or cleverness.
Three lines that someone else can read are better than one line that's tricky.

### Don't be defensive
Only catch exceptions that are truly exceptional. Assume that components we control will honor their contracts. If they don't, the solution is to find and fix the problem in code rather than cluttering the code with attempts to foresee all potential issues at runtime.

### Don't be afraid to add classes and methods
Code rarely suffers from too many methods and classes, and  often suffers from too few. Err on the side of numerous short, well-named methods. Pull out classes with well-defined roles.

### Rip shit out
Don't be afraid to delete code. Don't be afraid to rewrite something that needs to be refreshed. If it's in version control, we can always resurrect it.

### Maintain a consistent level of abstraction
Every line in a method should read at the same basic level of abstraction. If there's a section of a method that goes into a lot more detail than the rest of the method, consider extracting a new method and giving it a clear name.