├── LICENSE.txt └── README.md /LICENSE.txt: -------------------------------------------------------------------------------- 1 | Copyright 2014 ES6Rocks and other contributors, 2 | http://es6rocks.com/ 3 | 4 | This software consists of voluntary contributions made by many 5 | individuals. For exact contribution history, see the revision history 6 | available at https://github.com/es6rocks/code-style 7 | 8 | The following license applies to all parts of this software except as 9 | documented below: 10 | 11 | ==== 12 | 13 | Permission is hereby granted, free of charge, to any person obtaining 14 | a copy of this software and associated documentation files (the 15 | "Software"), to deal in the Software without restriction, including 16 | without limitation the rights to use, copy, modify, merge, publish, 17 | distribute, sublicense, and/or sell copies of the Software, and to 18 | permit persons to whom the Software is furnished to do so, subject to 19 | the following conditions: 20 | 21 | The above copyright notice and this permission notice shall be 22 | included in all copies or substantial portions of the Software. 23 | 24 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 25 | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 26 | MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 27 | NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE 28 | LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION 29 | OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION 30 | WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 31 | 32 | ==== 33 | 34 | Copyright and related rights for sample code are waived via CC0. Sample 35 | code is defined as all source code displayed within the prose of the 36 | documentation. 37 | 38 | CC0: http://creativecommons.org/publicdomain/zero/1.0/ 39 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # ES6Rocks Code Style 2 | 3 | This is fork from [jQuery Code Style] and follows the same licensing. 4 | [jQuery Code Style]: http://contribute.jquery.org/style-guide/js/ 5 | 6 | This style guide should be applied to all ES6Rocks code to improve readability and consistency. 7 | 8 | ## Spacing 9 | 10 | - Indentation: 4 spaces, no tabs. 11 | - No whitespace at the end of line or on blank lines. 12 | - Lines should be no longer than 100. There are 2 exceptions: 13 | - If the line contains a comment with a long URL. 14 | - If the line contains a regex literal. This prevents having to use the regex constructor which requires otherwise unnecessary string escaping. 15 | - `if`/`else`/`for`/`while`/`try` always have braces and always go on multiple lines. 16 | 17 | ```js 18 | // Bad 19 | if ( condition ) return; 20 | 21 | // Good 22 | if ( condition ) { 23 | return; 24 | } 25 | ``` 26 | 27 | - Unary special-character operators (e.g., `!`, `++`) must not have space next to their operand. 28 | - Any `,` and `;` must not have preceding space. 29 | - Any `;` used as a statement terminator must be at the end of the line. 30 | - Any `:` after a property name in an object definition must not have preceding space. 31 | - No filler spaces in empty constructs (e.g., `{}`, `[]`, `fn()`) 32 | - New line at the end of each file. 33 | 34 | ## Objects 35 | 36 | Object and array declarations can be made on a single line if they are short. When an object declaration is too long to fit on one line, there must be one property per line. 37 | 38 | Property names only need to be quoted if they are reserved words or contain special characters. 39 | 40 | ```js 41 | // Bad 42 | var map = { ready: 9, 43 | when: 4, 'you are': 15 }; 44 | 45 | // Good 46 | var map = { ready: 9, when: 4, 'you are': 15 }; 47 | 48 | // Good as well 49 | var map = { 50 | ready: 9, 51 | when: 4, 52 | 'you are': 15 53 | }; 54 | ``` 55 | 56 | ## Filler spaces 57 | 58 | - No filler spaces around one-line object and array elements neither function arguments list. 59 | - There should be a single space after each object/array element or function argument, preceded by `,`. 60 | - No filler space between the function name and its arguments parenthesis. 61 | - Unnamed expressions shouldn't have a filler space between `function` and its arguments parenthesis. 62 | - Braces should be preceded by a filler space when opening functions and blocks. 63 | 64 | ### Examples: 65 | ```js 66 | // Bad 67 | foo = [ a, b ]; 68 | 69 | // Good 70 | foo = [a, b]; 71 | ``` 72 | 73 | ```js 74 | // Bad 75 | function foo ( a, b, c ) { 76 | /* magic */ 77 | } 78 | 79 | // Good 80 | function foo(a, b, c) { 81 | /* magic */ 82 | } 83 | ``` 84 | 85 | ```js 86 | // Bad 87 | function (){ 88 | /* magic */ 89 | } 90 | 91 | // Good 92 | function() { 93 | /* magic */ 94 | } 95 | ``` 96 | 97 | ## Multi-line statements 98 | 99 | When a statement is too long to fit on one line, line breaks must occur after an operator. 100 | 101 | ```js 102 | // Bad 103 | html = '

The sum of ' + a + ' and ' + b + ' plus ' + c 104 | + ' is ' + (a + b + c); 105 | 106 | // Good 107 | html = '

The sum of ' + a + ' and ' + b + ' plus ' + c + 108 | ' is ' + (a + b + c); 109 | ``` 110 | 111 | Lines should be broken into logical groups if it improves readability, such as splitting each expression of a ternary operator onto its own line even if both will fit on a single line. 112 | 113 | ```js 114 | var baz = firstCondition( foo ) && secondCondition( bar ) ? 115 | qux( foo, bar ) : 116 | foo; 117 | ``` 118 | 119 | When a conditional is too long to fit on one line, successive lines must be indented one extra level to distinguish them from the body. 120 | 121 | ```js 122 | if ( firstCondition() && secondCondition() && 123 | thirdCondition() ) { 124 | doStuff(); 125 | } 126 | ``` 127 | 128 | ## Chained method calls 129 | 130 | When a chain of method calls is too long to fit on one line, there must be one call per line, with the first call on a separate line from the object the methods are called on. If the method changes the context, an extra level of indentation must be used. 131 | 132 | ```js 133 | // Bad 134 | parser.start().then(parser.clean).then(parser.getConfig) 135 | .then(parser.createPublicFolder).then(parser.compileCSS); 136 | 137 | // Good 138 | parser 139 | .start() 140 | .then(parser.clean) 141 | .then(parser.getConfig) 142 | .then(parser.createPublicFolder) 143 | .then(parser.compileCSS); 144 | ``` 145 | 146 | ## Assignments 147 | 148 | Assignments in a declaration must be on their own line. Declarations that don't have an assignment must be listed together at the start of the declaration. 149 | 150 | Declarations must be on the top of its scope. 151 | 152 | ```js 153 | // Bad 154 | var foo = true; 155 | var bar = false; 156 | var a; 157 | var b; 158 | var c; 159 | 160 | // Good 161 | var a, b, c, 162 | foo = true, 163 | bar = false; 164 | ``` 165 | 166 | ## Equality 167 | 168 | Strict equality checks (`===`) must be used in favor of abstract equality checks (`==`). The _only_ exception is when checking for `undefined` and `null` by way of `null`. 169 | 170 | ```js 171 | // Check for both undefined and null values, for some important reason. 172 | undefOrNull == null; 173 | ``` 174 | 175 | ## Comments 176 | 177 | Comments are always preceded by a blank line and must go over the line they refer to. 178 | 179 | There must be a single space between the comment token and the comment text. 180 | 181 | Multi-line comments - also named block level comments - are only used for file and function headers. 182 | 183 | ```js 184 | // We need an explicit "bar", because later in the code foo is checked. 185 | var foo = 'bar'; 186 | 187 | // Even long comments that span 188 | // multiple lines use the single 189 | // line comment form. 190 | ``` 191 | 192 | ## Quotes 193 | 194 | Use single quotes: `'`. Strings that require inner quoting must use single outside and double inside. 195 | 196 | ## Semicolons 197 | 198 | Use them. Never rely on ASI. 199 | 200 | ## Naming Conventions 201 | 202 | Variable and function names should be full words, using camel case with a lowercase first letter. Names should be descriptive but not excessively so. Exceptions are allowed for iterators, such as the use of i to represent the index in a loop. 203 | 204 | Constructors need a capital first letter, but modules do not. 205 | 206 | ## Switch statements 207 | 208 | The usage of switch statements is generally discouraged. 209 | 210 | ## Linting and checking 211 | 212 | - Use JSHint to detect errors and potential problems. JSHint options should be stored in a `.jshintrc` file. 213 | - Use JSCS to detect code style issues. JSCS options should be stored in a `.jscsrc` file. 214 | --------------------------------------------------------------------------------