{"_id":"59365227e16643001bac5044","category":{"_id":"59365227e16643001bac5033","version":"59365226e16643001bac5030","project":"543026235eceb608003fde5f","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2017-06-05T13:44:53.935Z","from_sync":false,"order":2,"slug":"contributing","title":"Contributing"},"project":"543026235eceb608003fde5f","user":"565743e4c19631170079793c","parentDoc":null,"version":{"_id":"59365226e16643001bac5030","project":"543026235eceb608003fde5f","__v":1,"createdAt":"2017-06-06T06:56:38.999Z","releaseDate":"2017-06-06T06:56:38.999Z","categories":["59365227e16643001bac5031","59365227e16643001bac5032","59365227e16643001bac5033","59365227e16643001bac5034"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0.0"},"__v":0,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2017-06-05T14:03:32.643Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"Good, clear and consistent code styles are pivotal in the success of any software project. Good use of style can reduce errors, consistency will enable us to work together efficiently. Ghost uses a combination of [JSHint](http://www.jshint.com/) and [JSCS](https://github.com/jscs-dev/node-jscs) to maintain consistent styles throughout the codebase which roughly emulate the strict style rules from JSLint.\n\n## The rules:\n\nYou can find the rules in the codebase. The root directory contains both a [.jshintrc](https://github.com/TryGhost/Ghost/blob/master/.jshintrc) and [.jscsrc](https://github.com/TryGhost/Ghost/blob/master/.jscsrc) file. Please note that the `/core/client/` directory, which contains the client-side ember code for the admin panel uses [ESLint](http://eslint.org/) and has its own [.eslintrc](https://github.com/TryGhost/Ghost-Admin/blob/master/.eslintrc.js) file. Many modern IDE's are able to pick up on these files and lint your code for you as you go.\n\nThe basic rules are:\n\n* `grunt lint` checks your code (`grunt validate` runs all tests).\n* Indent with 4 spaces.\n* Single quotes in JS.\n* One var per function.\n* Commas at the end.\n* Max line length 120.\n* Use unix line endings.\n* Don't litter with new lines\n* Document as you go.\n* Write tests.\n\n## Guidance\n\nA few key points to bear in mind. See also the [Zen of Python](http://www.python.org/dev/peps/pep-0020/) as it applies equally to JavaScript & Ghost.\n\n* **When coding, less is always more.** Write the least amount of code possible to solve just the problem at hand. \n* **Predicting the future is impossible.** Try to distinguish between anticipating potential future problems and potential future features. The former is usually good, the latter is usually bad.\n* **Callbacks are great, but promises and deferreds are even better.** We are using [bluebird](https://github.com/petkaantonov/bluebird) to provide promise functionality. In the vast majority of cases this is preferred to using callbacks.\n* **'exports' comes last.** Define the public API to your module at the very end of the file, even if it is a single function.\n* **Functional programming is functional.** Functions should be small and single-purpose. Large variable lists are a sign your function does too much.\n\n## Frontend development standards (HTML & CSS)\n\n- 4 spaces for HTML & CSS indentation. Never tabs.\n- Double quotes only, never single quotes.\n- Use tags and elements appropriate for an HTML5 doctype (e.g., self-closing tags)\n- Adhere to the [Recess CSS property order](http://markdotto.com/2011/11/29/css-property-order/).\n- Always a space after a property's colon (.e.g, `display: block;` and not `display:block;`).\n- End all lines with a semi-colon.\n- For multiple, comma-separated selectors, place each selector on its own line.\n\nFor more in depth information please read [Mark Otto](http://github.com/mdo)'s excellent [Code Guide](http://github.com/mdo/code-guide)","excerpt":"","slug":"code-standards","type":"basic","title":"Code Standards"}
Good, clear and consistent code styles are pivotal in the success of any software project. Good use of style can reduce errors, consistency will enable us to work together efficiently. Ghost uses a combination of [JSHint](http://www.jshint.com/) and [JSCS](https://github.com/jscs-dev/node-jscs) to maintain consistent styles throughout the codebase which roughly emulate the strict style rules from JSLint. ## The rules: You can find the rules in the codebase. The root directory contains both a [.jshintrc](https://github.com/TryGhost/Ghost/blob/master/.jshintrc) and [.jscsrc](https://github.com/TryGhost/Ghost/blob/master/.jscsrc) file. Please note that the `/core/client/` directory, which contains the client-side ember code for the admin panel uses [ESLint](http://eslint.org/) and has its own [.eslintrc](https://github.com/TryGhost/Ghost-Admin/blob/master/.eslintrc.js) file. Many modern IDE's are able to pick up on these files and lint your code for you as you go. The basic rules are: * `grunt lint` checks your code (`grunt validate` runs all tests). * Indent with 4 spaces. * Single quotes in JS. * One var per function. * Commas at the end. * Max line length 120. * Use unix line endings. * Don't litter with new lines * Document as you go. * Write tests. ## Guidance A few key points to bear in mind. See also the [Zen of Python](http://www.python.org/dev/peps/pep-0020/) as it applies equally to JavaScript & Ghost. * **When coding, less is always more.** Write the least amount of code possible to solve just the problem at hand. * **Predicting the future is impossible.** Try to distinguish between anticipating potential future problems and potential future features. The former is usually good, the latter is usually bad. * **Callbacks are great, but promises and deferreds are even better.** We are using [bluebird](https://github.com/petkaantonov/bluebird) to provide promise functionality. In the vast majority of cases this is preferred to using callbacks. * **'exports' comes last.** Define the public API to your module at the very end of the file, even if it is a single function. * **Functional programming is functional.** Functions should be small and single-purpose. Large variable lists are a sign your function does too much. ## Frontend development standards (HTML & CSS) - 4 spaces for HTML & CSS indentation. Never tabs. - Double quotes only, never single quotes. - Use tags and elements appropriate for an HTML5 doctype (e.g., self-closing tags) - Adhere to the [Recess CSS property order](http://markdotto.com/2011/11/29/css-property-order/). - Always a space after a property's colon (.e.g, `display: block;` and not `display:block;`). - End all lines with a semi-colon. - For multiple, comma-separated selectors, place each selector on its own line. For more in depth information please read [Mark Otto](http://github.com/mdo)'s excellent [Code Guide](http://github.com/mdo/code-guide)