├── ja ├── CONTRIBUTORS.md ├── Resources.md ├── README.md ├── JavaScript_Performance.md ├── Maintainable_JavaScript.md ├── Preventing_JavaScript_Errors.md └── Readable_JavaScript.md ├── Resources.md ├── README.md ├── JavaScript_Performance.md ├── Maintainable_JavaScript.md ├── LICENSE ├── Preventing_JavaScript_Errors.md └── Readable_JavaScript.md /ja/CONTRIBUTORS.md: -------------------------------------------------------------------------------- 1 | # 本ドキュメントを日本語に翻訳した人たち 2 | 3 | * [Hisashi Nakamura](https://github.com/sunvisor) : [http://www.sunvisor.net](http://www.sunvisor.net/) 4 | * [Shinobu Kawano](https://github.com/shinobukawano) : [http://shinobukawano.com](http://shinobukawano.com/) 5 | -------------------------------------------------------------------------------- /ja/Resources.md: -------------------------------------------------------------------------------- 1 |

2 | 3 | 4 |

5 | # 学習リソース 6 | 7 | このガイドはAirbnbの[この素晴らしいガイド](https://github.com/airbnb/javascript)からインスピレーションを得ています。ぜひそちらもご一読下さい。 8 | 9 | 本ドキュメントの各所に埋め込んだリンクのページに加えて、下記のページもご覧頂くことを強くお奨めいたします 10 | 。 11 | 12 | - [Code Conventions for the JavaScript Programming Language](http://javascript.crockford.com/code.html) from Douglass Crockford 13 | - [Google JavaScript Style Guide](http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml) from Google 14 | - [jQuery JavaScript Style Guide](http://contribute.jquery.org/style-guide/js/) from jQuery 15 | - [A JavaScript Quality Guide](https://github.com/bevacqua/js) from Nicolas Bevacqua 16 | - [Compiler-Friendly Code Guidelines](http://docs.sencha.com/cmd/5.x/cmd_compiler.html) from Sencha 17 | 18 | また、下記の書籍も非常にお奨めです。ぜひご拝読下さい。 19 | 20 | - [JavaScript: The Good Parts](http://) by Douglass Crockford 21 | - [テスト駆動JavaScript](http://) by Christian Johansen 22 | - [JavaScript Ninjaの秘密](http://) by John Resig 23 | - [Maintainable JavaScript](http://) by Nicholas Zakas 24 | -------------------------------------------------------------------------------- /Resources.md: -------------------------------------------------------------------------------- 1 |

2 | 3 | 4 |

5 | # Resources 6 | 7 | The original inspiration for this guide comes from the [fantastic guide](https://github.com/airbnb/javascript) 8 | put together by Airbnb. 9 | 10 | In addition to the many inline links our document contains, we strongly recommend you take a look at the following resources: 11 | 12 | - [Code Conventions for the JavaScript Programming Language](http://javascript.crockford.com/code.html) from Douglass Crockford 13 | - [Google JavaScript Style Guide](http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml) from Google 14 | - [jQuery JavaScript Style Guide](http://contribute.jquery.org/style-guide/js/) from jQuery 15 | - [A JavaScript Quality Guide](https://github.com/bevacqua/js) from Nicolas Bevacqua 16 | - [Compiler-Friendly Code Guidelines](http://docs.sencha.com/cmd/5.x/cmd_compiler.html) from Sencha 17 | 18 | 19 | We would also strongly encourage you to read the following books: 20 | 21 | - _JavaScript: The Good Parts_ by Douglass Crockford 22 | - _Test Driven JavaScript Development_ by Christian Johansen 23 | - _Secrets of the JavaScript Ninja_ by John Resig 24 | - _Maintainable JavaScript_ by Nicholas Zakas 25 | -------------------------------------------------------------------------------- /ja/README.md: -------------------------------------------------------------------------------- 1 |

2 | 3 | 4 |

5 | # SenchaのJavaScriptスタイルガイド&ベストプラクティス 6 | 7 | この文書は、JavaScriptとHTML5を利用してエンタープライズWebアプリケーションを開発する際のベストプラクティスや推奨事項をまとめたものです。 8 | 9 | 本文書のアドバイスは実際に当社（Sencha）の社内で使われているものです。Senchaフレームワークの構築に使われているスタイルガイドではありますが、他のフレームワークを利用している開発チームであっても有用だと考えています。もちろん、Vanilla JavaScriptの場合（\*）であっても変わりません。 10 | 11 | \*訳注 ... フレームワークを使わずにJavaScriptのコードを書くことを`Vanilla JavaScript`と呼びます。 12 | 13 | ## ミッションステートメント 14 | 15 | 高品質なJavaScriptは何よりも一貫性があり、次の4つの柱によって支えられているものであると固く信じています。 16 | 17 | - **可読性:** 明確で、一目で理解できること 18 | - **保守性:** 一貫性があり、まとまっていること 19 | - **例外の回避:** よくある問題を戦略的に避けていること 20 | - **パフォーマンス:** 常により速い実装を考慮していること 21 | 22 | このスタイルガイドは、JavaScriptとHTML5を利用してエンタープライズWebアプリケーションを構築するための、いくつかの基本原則を提供します。そして、主に中規模から大規模の開発チームを想定しています。 23 | 24 | 本文書の推奨は私たち自身の経験だけでなく、当社のお客様との対話も元にしています。 25 | 26 | ## 教義か方針か 27 | 28 | このスタイルガイドについて、必要以上に気にし過ぎないようにして下さい -- この文書は単なるガイドで、絶対に守らなければならない教義ではありません。 29 | 30 | 本ガイドは「ベストプラクティス」についての網羅的な一覧を目指していません。それよりも、皆さんがよく私たちに質問される関心事について答えようとしています。それらについては、他の多くの方も [似たような文書](Resources.md) を既に作成されており、全体で明らかな同意が取れていないトピックかと存じます。 31 | 32 | この文書の全体的な目標は、コードの「品質」について私たちが重要だと考えている事柄をあなたが検討する手助けを行うことです。そして最終的には、あなたが読みやすく、保守しやすく、拡張性の高いプロジェクトを作成することを目指しています。私たちの提案は、高品質なJavaScriptのコードベースを構築する戦略を組み立てる際の、開発チームが考慮すべきベースラインだと考えて頂ければ幸いです。 33 | 34 | # 概要 35 | 36 | 当社でのフレームワークとエンタープライズ・アプリケーションを構築した経験から、この議論については、次の4つの部分に分割させて頂きます。 37 | 38 | 1. [可読性](Readable_JavaScript.md) 39 | 2. [保守性](Maintainable_JavaScript.md) 40 | 3. [例外の回避](Preventing_JavaScript_Errors.md) 41 | 4. [パフォーマンス](JavaScript_Performance.md) 42 | 43 | 44 | これら以上に多くの内容についてカバーすることは、あまり価値がないと思われます。 45 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |

2 | 3 | 4 |

5 | # Sencha's Guide to JavaScript Style and Best Practices 6 | 7 | The following document contains a series of best practices and recommendations for building enterprise web applications 8 | with JavaScript and HTML5. 9 | 10 | Much of this advice is used internally at Sencha and certainly applies to building applications with the Sencha 11 | frameworks -- but this JavaScript style guide can also help teams building applications with any framework, or 12 | even just vanilla JavaScript. 13 | 14 | ## Mission Statement 15 | 16 | Sencha firmly believes that high quality JavaScript is above all else consistent, and addresses four main pillars: 17 | 18 | - **Readability:** JavaScript code should be clear and easy to understand at first glance 19 | - **Maintainability:** JavaScript code should be consistent and cohesive 20 | - **Error Prevention:** JavaScript code should strategically avoid common problems 21 | - **Performance:** JavaScript code should always consider faster implementations 22 | 23 | This style guide will attempt to provide some ground rules for building enterprise web applications with JavaScript and 24 | HTML5, and as such is intended primarily for medium-to-large development teams. 25 | 26 | These recommendations are based on our own experiences, as well as direct interaction with our enterprise customers. 27 | 28 | ## Dogma vs Doctrine 29 | 30 | Avoid obsessing about code style -- this document is merely a guide, not infallible dogma. It is not intended to be a 31 | comprehensive list of all "best practices", but rather a list of the most common areas on which people ask our 32 | opinions. Many others have created [similar documents](Resources.md) and clearly not everyone agrees on every point. 33 | 34 | The overall goal for this document is to help you evaluate what we consider to be the important aspects of "quality" 35 | code, and ultimately create your own readable, maintainable and scalable JavaScript projects. Our suggestions stand as 36 | a baseline from which your teams should implement your own strategy for building a high quality JavaScript codebase. 37 | 38 | # Outline 39 | 40 | To best articulate Sencha's experience building both frameworks and enterprise applications, we will divide this 41 | discussion into four parts: 42 | 43 | 1. [Readability](Readable_JavaScript.md) 44 | 2. [Maintainability](Maintainable_JavaScript.md) 45 | 3. [Preventing Errors](Preventing_JavaScript_Errors.md) 46 | 4. [Performance](JavaScript_Performance.md) 47 | 48 | It is worth noting that many of the points we will cover might fit into more than one of these pillars. -------------------------------------------------------------------------------- /ja/JavaScript_Performance.md: -------------------------------------------------------------------------------- 1 |

2 | 3 | 4 |

2 | 3 | 4 |

2 | 3 | 4 |

2 | 3 | 4 |

2 | 3 | 4 |

2 | 3 | 4 |

2 | 3 | 4 |

2 | 3 | 4 |

5 | # Writing Readable JavaScript 6 | 7 | The importance of writing "readable" JavaScript simply cannot be overstated. Be kind to the others on your team, 8 | and your future self, by writing code that is easy to digest. 9 | 10 | In his book *Facts and Fallacies of Software Engineering*, Robert Glass discusses how simply 11 | "understanding the existing product" consumes roughly 30% of a developer's time. Glass frames this point within the 12 | context of the software maintenance cycle -- and while we will move our discussion to maintainability soon, 13 | Sencha recommends prioritizing the following points to make your codebase clear and coherent: 14 | 15 | - [Naming Conventions](#Naming_Conventions) 16 | - [Comments and Documentation](#Comments_Documentation) 17 | - [Documenting Overrides](#Documenting_Overrides) 18 | - [Spacing and White Space](#Spacing_White_Space) 19 | - [Line Length](#Line_Length) 20 | - [Block Length](#Block_Length) 21 | - [File Length](#File_Length) 22 | 23 | ## Naming Conventions 24 | 25 | > *"There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors."* 26 | 27 | Many people only name a few things in their life: a pet, a child, or something particularly personal and meaningful. 28 | In general, naming things is difficult because there is a perceived finality to the process 29 | (e.g. you rarely re-name a pet) -- but in software development, one typically has to name things far more often 30 | than the average person. 31 | 32 | Software developers might name thousands of new things per year: variables, classes, applications, etc. Each name 33 | attempts to capture the essence or purpose of the concept being named -- but because programs use more names than 34 | can be reasonably remembered, the names must be conceived consistently in order to help others understand, fix, 35 | and extend that same code months or years later. This idea is often referred to as "self-documenting code". 36 | 37 | Let's examine the areas in which naming conventions should be applied and how Sencha handles each case. 38 | 39 | ### Namespaces, Classes, and Constructors 40 | 41 | Sencha always uses *TitleCase* when creating top-level namespaces, classes, and constructors. 42 | 43 | // "MyClass" is a constructor :: new MyClass(); 44 | MyClass = function () {}; 45 | 46 | Intermediate namespaces should be short, descriptive and lowercase. 47 | 48 | // "Foo" as the top-level namespace 49 | // "bar" as an intermediate-level namespace 50 | // "Baz" as the class name 51 | Foo.bar.Baz = {}; 52 | Ext.data.reader.Json = {}; 53 | 54 | ### Functions 55 | 56 | Sencha always uses *camelCase* when creating functions. We also recommend the use a leading underscore "_" when 57 | naming private functions and methods that are not encapsulated by a closure. 58 | 59 | // function expression 60 | var sortSomeStuff = function () {}; 61 | 62 | // function declaration 63 | function findSomething () {} 64 | 65 | // the same concept applies to object functions 66 | var someObject = { 67 | objectMethod: function () {}, 68 | 69 | _privateMethod: function () {} 70 | }; 71 | 72 | Note: more information about using function expressions vs. function declarations can be found in 73 | section [Functions](Preventing_JavaScript_Errors.md#Functions). 74 | 75 | ### Local Variables and Object Properties 76 | 77 | Always use `var` to declare local variables -- not doing so will result in the creation of global variables, and we want 78 | to avoid polluting the global namespace. See the [Constants and Global Variables](#Constants_Global_Vars) section below 79 | for more details. 80 | 81 | // bad 82 | foo = true; 83 | 84 | // good 85 | var foo = true; 86 | 87 | Sencha always uses *camelCase* when creating local variables and object properties. We also recommend the use a 88 | leading underscore "_" when naming private properties. 89 | 90 | // local variable 91 | var fooBar = true; 92 | 93 | // object property 94 | var someObject = { 95 | someProperty: true, 96 | 97 | _privateProperty: true 98 | }; 99 | 100 | Variables should be given meaningful names, so that the intended purpose and functionality of the variables is 101 | clear (while also concise). Avoid single letter names; the lone exception to this rule would be an iterator. 102 | 103 | // bad, too short. Not descriptive and easy to confuse with number "1" 104 | var l = group.length; 105 | 106 | // bad, variable name is unnecessarily long 107 | var mainClassConfigVariableSectionOneRefreshInterval = 5000; 108 | 109 | // good, variable name is concise yet still meaningful 110 | var len = group.length; 111 | 112 | // iterators are an exception 113 | var i; 114 | for (i = 0; i < len; i++) {} 115 | 116 | Use one `var` declaration when creating multiple variables because it is easier to read. Sencha recommends 117 | declaring each variable assignment on a new line; declare unassigned variables last, though these can be on the 118 | same line. 119 | 120 | This helps to provide a visual cue to the person reading your code about the initial state of the variables 121 | within the current scope. 122 | 123 | // bad 124 | var foo = 1; 125 | var bar = 2; 126 | var baz; 127 | var fuz; 128 | 129 | // good 130 | var foo = 1, 131 | bar = 2, 132 | baz, fuz; 133 | 134 | ### Constants and Global Variables 135 | 136 | Sencha recommends using *CONSTANT_CASE* when creating global variables because of the clear visual 137 | indication that the variable is special. 138 | 139 | // bad 140 | userID = '12345'; 141 | 142 | // good 143 | USER_ID = '12345'; 144 | 145 | Having said that, Sencha prefers to avoid global variables and constants altogether. We feel that enterprise 146 | applications benefit from using properly-namespaced classes instead because it's always clear where a value 147 | has been defined. 148 | 149 | // better 150 | MyApp.authentication.User = { 151 | id: '12345' 152 | }; 153 | 154 | ### Special Cases 155 | 156 | Other special cases also exist -- for example, naming references to `this`. 157 | 158 | As an internal convention, Sencha uses the name `me` when there is a need to capture a reference to `this` within 159 | a closure. Not everyone agrees -- Christian Johansen is [a notable example](https://gist.github.com/cjohansen/4135065) -- 160 | but the greater point is to manage these special cases consistently throughout your codebase. 161 | 162 | Person.logger = function () { 163 | var me = this; // "me" will be used consistently 164 | 165 | return function () { 166 | console.log(me); 167 | }; 168 | }; 169 | 170 | Another important thing to note is that `this` is a keyword and can't be compressed. In the Sencha frameworks, 171 | we abide by the rule of four: if a given scope references `this` four or more times, 172 | cache `this` using the local variable `me` as it will make the minified source smaller. 173 | 174 | // bad 175 | function foo () { 176 | this.x = 1; 177 | this.y = 2; 178 | this.z = 3; 179 | this.u = 4; 180 | } 181 | 182 | // good 183 | function foo () { 184 | var me = this; 185 | me.x = 1; 186 | me.y = 2; 187 | me.z = 3; 188 | me.u = 4; 189 | } 190 | 191 | // comparison of minified output 192 | function f(){this.x=1;this.y=2;this.z=3} 193 | function f(){var e=this;e.x=1;e.y=2;e.z=3} 194 | 195 | function f(){this.x=1;this.y=2;this.z=3;this.u=4;} 196 | function f(){var e=this;e.x=1;e.y=2;e.z=3;e.u=4;} // 4 is now shorter! 197 | 198 | function f(){this.x=1;this.y=2;this.z=3;this.u=4;this.v=5;} 199 | function f(){var e=this;e.x=1;e.y=2;e.z=3;e.u=4;e.v=5;} 200 | 201 | ### Reserved Words 202 | 203 | Don't use reserved words as keys because they break things in older versions of Internet Explorer. Use readable synonyms 204 | in place of reserved words instead. 205 | 206 | // bad 207 | var model = { 208 | name: 'Foo', 209 | private: true // reserved word! 210 | }; 211 | 212 | // good 213 | var model = { 214 | name: 'Foo', 215 | hidden: true 216 | }; 217 | 218 | 219 | Note: "readable synonyms" must actually be words. 220 | 221 | // bad 222 | var car = { 223 | class: 'Ford' // reserved word! 224 | }; 225 | 226 | // bad 227 | var car = { 228 | klass: 'Ford' // PLEASE don't ever do this! 229 | }; 230 | 231 | // good 232 | var car = { 233 | brand: 'Ford' 234 | }; 235 | 236 | ## Comments and Documentation 237 | 238 | Generally speaking, good code is supposed to be self-explanatory. However comments play two vital roles in promoting 239 | readable code: documentation, and intent (via inline comments). 240 | 241 | ### Documentation 242 | 243 | System-wide documentation is vital to developing large codebases. Using tools like 244 | [JSDuck](https://github.com/senchalabs/jsduck) it is easy to build an API 245 | reference for your codebase, making it significantly easier for your team (and others) to digest. 246 | 247 | [Sencha](http://docs.sencha.com/extjs/5.0/apidocs/) uses JSDuck internally, which follows the JavaDoc style for block 248 | comments. See the [JSDuck wiki](https://github.com/senchalabs/jsduck/wiki) for more information. 249 | 250 | /** 251 | * @class MyApp.foo.Bar 252 | */ 253 | MyApp.foo.Bar = function () { 254 | var baz = true; 255 | 256 | return { 257 | /** 258 | * @method 259 | */ 260 | utilityMethod: function () { 261 | return baz; 262 | } 263 | }; 264 | }; 265 | 266 | ### Inline Comments 267 | 268 | Many developers feel that code ought to be "self-documenting" and therefore inline comments are to be avoided. 269 | Sencha doesn't necessarily agree with the rigidness of that mindset; we believe that comments should always be 270 | added when the intent or purpose of any code isn't completely explicit, but the code itself ought to be clear 271 | enough to follow logically. 272 | 273 | // In a majority of cases, the controller ID will be the same as the name. 274 | // However, when a controller is manually given an ID, it will be keyed 275 | // in the collection that way. So if we don't find it, we attempt to loop 276 | // over the existing controllers and find it by classname 277 | if (!controller) { 278 | all = controllers.items; 279 | for (i = 0, len = all.length; i < len; ++i) { 280 | cls = all[i]; 281 | className = cls.getModuleClassName(); 282 | if (className && className === name) { 283 | controller = cls; 284 | break; 285 | } 286 | } 287 | } 288 | 289 | Regular expressions should also always be explained with a comment because of their inherently confusing syntax. 290 | 291 | // match Roman Number input 292 | var romanNums = /^M{0,4}(CM|CD|D?C{0,3})(XC|XL|L?X{0,3})(IX|IV|V?I{0,3})$/; 293 | 294 | Commenting out entire blocks of code should be generally avoided because they serve no purpose and create bloated code. 295 | 296 | // Why leave the following code in production? 297 | items : [ 298 | //{ 299 | // xtype : 'booleancolumn', 300 | // width : 5, 301 | // resizable : false, 302 | // defaultWidth : 5, 303 | // sortable : false, 304 | // dataIndex : 'isOwn', 305 | // groupable : false, 306 | // hideable : false, 307 | // lockable : false, 308 | // tdCls : 'indicator', 309 | // falseText : ' ', 310 | // trueText : ' ' 311 | //}, 312 | //{ 313 | // xtype : 'gridcolumn', 314 | // dataIndex : 'key', 315 | // text : 'Binding Key', 316 | // flex : 1 317 | //}, 318 | { 319 | xtype : 'templatecolumn', 320 | dataIndex : 'boundTo', 321 | text : 'Bound To', 322 | flex : 1, 323 | tpl : '\\{{boundTo}\\}' 324 | }, 325 | { 326 | xtype : 'gridcolumn', 327 | dataIndex : 'value', 328 | text : 'Value', 329 | flex : 1, 330 | renderer : function (value, metaData, record, rowIndex, colIndex, store, view) { 331 | var v = value; 332 | 333 | if (value === null) { 334 | v = 'null'; 335 | } 336 | 337 | if (record.data.text === 'undefined') { 338 | v = 'undefined'; 339 | } 340 | 341 | return '' + v + ''; 342 | } 343 | } 344 | ] 345 | 346 | ## Documenting Overrides 347 | 348 | In cases where you need to override default or inherited functionality, both inline and block comments are 349 | actively encouraged so that the changes are perfectly clear. 350 | 351 | // OVERRIDE for bug EXTJS-12345 352 | Ext.define('MyApp.override.CustomNumberField', { 353 | override : 'Ext.form.field.Number', 354 | 355 | initComponent: function () { 356 | var me = this, 357 | allowed; 358 | 359 | me.callParent(); 360 | 361 | me.setMinValue(me.minValue); 362 | me.setMaxValue(me.maxValue); 363 | 364 | // Build regexes for masking and stripping based on the configured options 365 | if (me.disableKeyFilter !== true) { 366 | allowed = me.baseChars + ''; 367 | if (me.allowDecimals) { 368 | //OVERRIDE THIS LINE... 369 | //allowed += me.decimalSeparator; 370 | allowed += ',.'; 371 | } 372 | } 373 | } 374 | }); 375 | 376 | This documentation will often come in handy during an upgrade process. For example, the bug EXTJS-12345 might have 377 | been fixed in the latest version -- so this override could be removed completely. 378 | 379 | ## Spacing and White Space 380 | 381 | Many developers have strong opinions on the topic of tabs-vs-spaces for spacing. Sencha advocates the use of 382 | four spaces in our own code because tab sizes are unpredictable; the only way we can guarantee readable code is 383 | to enforce the use of spaces. Ultimately the goal is just to have consistency, so whatever your choice don't mix them! 384 | 385 | // bad 386 | function doSomething (isTrue) { 387 | // < 1 space in 388 | if (isTrue) { 389 | // <<< 3 spaces in? 390 | }// now you're just being confusing... 391 | } 392 | 393 | // good 394 | function doSomething (isTrue) { 395 | // <<<< 4 spaces in! 396 | if (isTrue) { 397 | // <<<< 4 spaces in again! 398 | } 399 | } 400 | 401 | On the other hand, Sencha also advocates for using as much white space as necessary to make your code easier to read. 402 | 403 | ### Benefits of Consistency 404 | 405 | One technique Sencha recommends is to maintain spaces before the parentheses of function declarations but 406 | not for function calls. This allows text searches to more easily find calls to functions separately from their 407 | declartions. 408 | 409 | For example: 410 | 411 | function foo () { // Note the space between "foo" and "(" 412 | return 42; 413 | } 414 | 415 | var x = foo(); // Note no space between "foo" and "(" 416 | 417 | Now searches for "foo(" will find only the calls to `foo`. 418 | 419 | Another technique Sencha recommends is to place no space between the name of an object property and the `:` 420 | (again for benefits in text search). 421 | 422 | For example: 423 | 424 | Ext.define('Ext.panel.Panel', { 425 | collapse: function () ... 426 | }); 427 | 428 | Searches for "collapse:" will find implementations of `collapse` and not invocations. Conversely for 429 | "collapse(". 430 | 431 | ## Line Length 432 | 433 | Not everyone agrees with the specific limit for characters-per-line, but Sencha generally tries to limit line length. 434 | This limit can be arbitrary (e.g. 80 or 100 characters) and not rigidly enforced, but the goal is to reduce the amount 435 | of horizontal scrolling for the developer. 436 | 437 | Strings longer than the decided limit should be written across multiple lines using string concatenation. 438 | 439 | ## Method and Block Length 440 | 441 | How long can a method or code block get before you consider breaking functionality into smaller utility methods? 442 | 443 | A good rule-of-thumb is to limit the length of method and code blocks (e.g. 50 or 100 lines) so that they are not 444 | trying to do too much. Shorter methods are easier to test, and smaller sections of code are more quickly 445 | comprehended by developers. 446 | 447 | ## File Length 448 | 449 | How long should a file be before you consider breaking functionality into mixins, modules or other utility classes? 450 | 451 | As with method/block length, comments can easily impact the length of a file. Abstract classes might also be longer 452 | than usual because they define interfaces and baseline functionality. Nevertheless, defining an arbitrary file 453 | length (e.g. 500 or 1000 lines) might give you an indication of whether-or-not a class might need to be refactored. 454 | --------------------------------------------------------------------------------