🚨 Contributing to Atom 🚨

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 and CSS styleguides
Include thoughtfully worded 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 💄
Commit messages that improve the performance start with 🐎
Commit messages that remove memory leaks start with 🚱
Commit messages that improve documentation start with 📝
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
Beware 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.

4.1 KiB Raw Blame History