Chromium Code Reviews| OLD | NEW |
|---|---|
| 1 Sky Style Guide | 1 Sky Style Guide |
| 2 =============== | 2 =============== |
| 3 | 3 |
| 4 In general, follow our [Design Principles](design.md) for all code. | 4 In general, follow our [Design Principles](design.md) for all code. |
| 5 | 5 |
| 6 The primary goal of this style guide is to improve code readability so | |
| 7 that everyone, whether reading the code for the first time or | |
| 8 maintaining it for years, can quickly determine what the code does. A | |
| 9 secondary goal is avoiding arguments when there are disagreements. | |
| 6 | 10 |
| 7 Dart | 11 Dart |
| 8 ---- | 12 ---- |
| 9 | 13 |
| 10 In general, follow the [Dart style | 14 In general, follow the [Dart style |
| 11 guide](https://www.dartlang.org/articles/style-guide/) for Dart code, | 15 guide](https://www.dartlang.org/articles/style-guide/) for Dart code, |
| 12 except where that would contradict this page. | 16 except where that would contradict this page. |
| 13 | 17 |
| 14 Always use the Dart Analyzer. Do not check in code that increases the | 18 Always use the Dart Analyzer. Do not check in code that increases the |
| 15 output of the analyzer unless you've filed a bug with the Dart team. | 19 output of the analyzer unless you've filed a bug with the Dart team. |
| (...skipping 60 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
| 76 | 80 |
| 77 When breaking a parameter list into multiple lines, do the same. | 81 When breaking a parameter list into multiple lines, do the same. |
| 78 | 82 |
| 79 Use // and ///, not /* */ and /** */. | 83 Use // and ///, not /* */ and /** */. |
| 80 | 84 |
| 81 Don't put the statement part of an "if" statement on the same line as | 85 Don't put the statement part of an "if" statement on the same line as |
| 82 the expression, even if it is short. (Doing so makes it unobvious that | 86 the expression, even if it is short. (Doing so makes it unobvious that |
| 83 there is relevant code there. This is especially important for early | 87 there is relevant code there. This is especially important for early |
| 84 returns.) | 88 returns.) |
| 85 | 89 |
| 90 If a flow control structure has just one statement, then don't use | |
| 91 braces around it except where doing so would help readability or avoid | |
| 92 the dangling-else problem. Keeping the code free of boilerplate or | |
| 93 redundant punctuation keeps it concise and readable. | |
| 94 | |
| 95 > For example, | |
| 96 > ```dart | |
| 97 > if (children != null) | |
| 98 > for (RenderBox child in children) | |
| 99 > add(child); | |
|
abarth-chromium
2015/06/25 17:17:12
The usual Google style for this situation is to pu
| |
| 100 > ``` | |
| 101 > ...rather than: | |
| 102 > ```dart | |
| 103 > if (children != null) { | |
| 104 > for (RenderBox child in children) { | |
| 105 > add(child); | |
| 106 > } | |
| 107 > } | |
| 108 > ``` | |
| 109 | |
| 86 | 110 |
| 87 Use the most relevant constructor or method, when there are multiple | 111 Use the most relevant constructor or method, when there are multiple |
| 88 options. | 112 options. |
| 89 | 113 |
| 90 > For example, | 114 > For example, |
| 91 > ```dart | 115 > ```dart |
| 92 > new EdgeDims.symmetric(horizontal: 8.0); | 116 > new EdgeDims.symmetric(horizontal: 8.0); |
| 93 > ``` | 117 > ``` |
| 94 > ...rather than: | 118 > ...rather than: |
| 95 > ```dart | 119 > ```dart |
| 96 > new EdgeDims(0.0, 8.0, 0.0, 8.0); | 120 > new EdgeDims(0.0, 8.0, 0.0, 8.0); |
| 97 > ``` | 121 > ``` |
| 98 | 122 |
| 99 | 123 |
| 100 C++ | 124 C++ |
| 101 --- | 125 --- |
| 102 | 126 |
| 103 | 127 |
| 104 Java | 128 Java |
| 105 ---- | 129 ---- |
| 106 | 130 |
| OLD | NEW |