please see the document [How to Contribute](https://github.com/Microsoft/vscode/tree/master/wiki/contributing/how-to-contribute.md), which covers the following:

* [How to build and run from source](https://github.com/Microsoft/vscode/tree/master/wiki/contributing/how-to-contribute.md#build-and-run-from-source)

* [The development workflow, including debugging and running tests](https://github.com/Microsoft/vscode/tree/master/wiki/contributing/how-to-contribute.md#development-workflow)

* [Coding Guidelines](https://github.com/Microsoft/vscode/tree/master/wiki/contributing/coding-guidelines.md)

* [Submitting pull requests](https://github.com/Microsoft/vscode/tree/master/wiki/contributing/how-to-contribute.md#pull-requests)

For a complete list, please see the [Related Projects](https://github.com/Microsoft/vscode/tree/master/wiki/project-management/related-projects.md) page on our wiki.

The best way to run the Code tests is from within VS Code. Simply press `CMD+Shift+T` (`Ctrl+Shift+T` on Windows) to launch the tests. To make development changes to unit tests you need to be running `gulp`. See [Development Workflow](https://github.com/Microsoft/vscode/tree/master/wiki/contributing/how-to-contribute.md#incremental-build) for more details.

Welcome to the Code Wiki. These pages are primarily intended for those who wish to contribute to the Code project by submitting bug reports, suggesting new features, building extensions, commenting on new ideas, or even by submitting pull requests.

Please refer to the sidebar (on the right) for details on Project Management, Contributing to Code, and Documentation.

If you are looking for more information on using VS Code, please visit our [the Visual Studio Code portal](http://code.visualstudio.com) and follow us on [Twitter](https://twitter.com/code)!

- Contributing

- [How to Contribute](contributing/how-to-contribute.md)

- [Submitting Bugs and Suggestions](contributing/submitting-bugs-and-suggestinos.md)

- [Code Organization](contributing/code-organization.md)

- [Coding Guidelines](contributing/coding-guidelines.md)

- [Contributor License Agreement](contributing/contributor-license-agreement.md)

- [Requested Extensions](contributing/requested-extensions.md)

- Project Management

- [Roadmap](project-management/roadmap.md)

- [Iteration Plans](project-management/iteration-plans.md)

- [Breaking Changes](project-management/breaking-changes.md)

- [Development Process](project-management/development-process.md)

- [Issue Tracking](project-management/issue-tracking.md)

- [Previous Releases](project-management/previous-releases.md)

- [Related Projects](project-management/related-projects.md)

- [Documentation](https://code.visualstudio.com/docs)

- [Extensions](https://code.visualstudio.com/docs/extensions/overview)

- [API](https://code.visualstudio.com/docs/extensionAPI/overview)

- [Documetnation repository](https://github.com/microsoft/vscode-docs)

Code consists a layered and modular `core` that can be extended using extensions. Extensions are run in a separate process refered to as the

`extension host.` Extensions are implemented by utilizing the [extension API](https://code.visualstudio.com/docs/extensions/overview).

The `core` is partitioned into the following layers:

- `base`: Provides general utilities and user interface building blocks

- `platform`: Defines service injection support and the base services for Code

- `editor`: The "Monaco" editor is available as a separate downloadable component

- `languages`: For historical reasons, not all languages are implemented as extensions (yet) - as Code evolves we will migrate more languages to towards extensions

- `workbench`: Hosts the "Monaco" editor and provides the framework for "viewlets" like the Explorer, Status Bar, or Menu Bar, leveraging [Electron](http://electron.atom.io/) to implement the Code desktop application.

The `core` of Code is fully implemented in [TypeScript](https://github.com/microsoft/typescript). Inside each layer the code is organized by the target runtime environment. This ensures that only the runtime specific APIs are used. In the code we distinguish between the following target environments:

- `common`: Source code that only requires basic JavaScript APIs and run in all the other target environments

- `browser`: Source code that requires the `browser` APIs like access to the DOM

- may use code from: `common`

- `node`: Source code that requires [`nodejs`](https://nodejs.org) APIs

- may use code from: `common`

- `electron-browser`: Source code that requires the [Electron renderer-process](https://github.com/atom/electron/tree/master/docs#modules-for-the-renderer-process-web-page) APIs

- may use code from: `common`, `browser`, `node`

- `electron-main`: Source code that requires the [Electron main-process](https://github.com/atom/electron/tree/master/docs#modules-for-the-main-process) APIs

- may use code from: `common`, `node`

The code is organised around services of which most are defined in the `platform` layer. Services get to its clients via `constructor injection`.

A service definition is two parts: (1) the interface of a service, and (2) a service identifier - the latter is required because TypeScript doesn't use nominal but structural typing. A service identifier is a decoration (as proposed for ES7) and should have the same name as the service interface.

Declaring a service dependency happens by adding a corresponding decoration to a constructor argument. In the snippet below `@IModelService` is the service identifier decoration and `IModelService` is the (optional) type annotation for this argument.

class Client {

constructor(@IModelService modelService: IModelService) {

// use modelService

}

}

Use the instantiation service to create instances for service consumers, like so `instantiationService.createInstance(Client)`. Usually, this is done for you when being registered as a contribution, like a Viewlet or Language.

We prefer a **rebase workflow** and occasional **feature branches**. Most work happens directly on the `master` branch. For that reason, we recommend setting the `pull.rebase` setting to true.

We use tabs, not spaces.

* Use PascalCase for `type` names

* Use PascalCase for `enum` values

* Use camelCase for `function` and `method` names

* Use camelCase for `property` names and `local variables`

* Use whole words in names when possible

* Do not export `types` or `functions` unless you need to share it across multiple components

* Do not introduce new `types` or `values` to the global namespace

* Use JSDoc style comments for `functions`, `interfaces`, `enums`, and `classes`

* Use "double quotes" for strings shown to the user that need to be externalized (localized)

* Use 'single quotes' otherwise

* All strings visible to the user need to be externalized

* Use arrow functions `=>` over anonymous function expressions

* Only surround arrow function parameters when necessary. For example, `(x) => x + x` is wrong but the following are correct:

``` javascript

x => x + x

(x,y) => x + y

<T>(x: T, y: T) => x === y

* Always surround loop and conditional bodies with curly braces

* Open curly braces always go on the same line as whatever necessitates them

* Parenthesized constructs should have no surrounding whitespace. A single space follows commas, colons, and semicolons in those constructs. For example:

``` javascript

for (var i = 0, n = str.length; i < 10; i++) { }

if (x < 10) { }

function f(x: number, y: string): void { }

You must sign a Contribution License Agreement (CLA) before your PR will be merged. This a one-time requirement for Microsoft projects in GitHub. You can read more about [Contribution License Agreements (CLA)](https://en.wikipedia.org/wiki/Contributor_License_Agreement) on Wikipedia.

However, you don't have to do this up-front. You can simply clone, fork, and submit your pull-request as usual.

When your pull-request is created, it is classified by a CLA bot. If the change is trivial (i.e. you just fixed a typo) then the PR is labelled with `cla-not-required`. Otherwise, it's classified as `cla-required`. In that case, the system will also tell you how you can sign the CLA. Once you have signed a CLA, the current and all future pull-requests will be labelled as `cla-signed`.

Signing the CLA might sound scary but it's actually very simple and can be done in less than a minute.