Chromium Code Reviews| OLD | NEW |
|---|---|
| (Empty) | |
| 1 Sky Style Guide | |
|
Matt Perry
2015/06/10 18:36:49
Should mention near the top that this is specifica
| |
| 2 =============== | |
| 3 | |
| 4 Always use the Dart Analyzer. Do not check in code that increases the | |
| 5 output of the analyzer unless you've filed a bug with the Dart team. | |
| 6 | |
| 7 Use assert()s liberally. | |
| 8 | |
| 9 | |
| 10 Classes and Enums are named UpperCamelCase. Everything else (methods, | |
| 11 fields, variables, constants, enum values, etc) is lowerCamelCase. | |
| 12 Global double and string constants are prefixed with k. Prefer using a | |
| 13 static const in a relevant class than using a global constant. | |
| 14 | |
| 15 Don't name your libraries (no ```library``` keyword). Name the files | |
| 16 in ```lower_under_score.dart``` format. | |
| 17 | |
| 18 | |
| 19 Class constructors and methods should be ordered in the order that | |
| 20 their members will be used in an instance's typical lifecycle. In | |
| 21 particular, this means constructors all come first in class | |
| 22 declarations. | |
| 23 | |
| 24 The default (unnamed) constructor should come first, then the named | |
| 25 constructors. | |
| 26 | |
| 27 Fields should come before the methods that manipulate them, if they | |
| 28 are specific to a particular group of methods. | |
| 29 | |
| 30 > For example, RenderObject groups all the layout methods and layout | |
| 31 > fields together, then all the paint methods and paint fields. | |
| 32 | |
| 33 Fields that aren't specific to a particular group of methods should | |
| 34 come immediately after the constructors. | |
| 35 | |
| 36 Be consistent in the order of members. If a constructor lists a bunch | |
| 37 of fields, then those fields should declared be in the same order, and | |
| 38 any code that operates on all of them should operate on them in the | |
| 39 same order (unless the order matters). | |
| 40 | |
| 41 | |
| 42 All variables and arguments are typed; don't use "var", "dynamic", or | |
| 43 "Object" in any case where you could figure out the actual type. | |
| 44 Always specialise generic types where possible. Even for ```[]``` and | |
| 45 ```{}``` literals, include the types. | |
| 46 | |
| 47 Aim for a line length of 80 characters, but go over if breaking the | |
| 48 line would make it less readable. | |
| 49 | |
| 50 Only use => when the result fits on a single line. | |
| 51 | |
| 52 When using ```{ }``` for an empty block of code, put a single space | |
| 53 between the two braces. | |
| 54 | |
| 55 Use // and ///, not /* */ and /** */. | |
| 56 | |
| 57 Don't put the statement part of an "if" statement on the same line as | |
| 58 the expression, even if it is short. (Doing so makes it unobvious that | |
| 59 there is relevant code there. This is especially important for early | |
| 60 returns.) | |
| 61 | |
| 62 | |
| 63 Use the most relevant constructor or method, when there are multiple | |
| 64 options. | |
| 65 | |
| 66 > For example, | |
| 67 > ```dart | |
| 68 > new EdgeDims.symmetric(horizontal: 8.0); | |
| 69 > ``` | |
| 70 > ...rather than: | |
| 71 > ```dart | |
| 72 > new EdgeDims(0.0, 8.0, 0.0, 8.0); | |
| 73 > ``` | |
| 74 | |
| 75 | |
| 76 In general, follow our [Design Principles](design.md) and the [Dart | |
| 77 style guide](https://www.dartlang.org/articles/style-guide/) where | |
| 78 doing so wouldn't contradict the above. | |
| OLD | NEW |