Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(267)

Side by Side Diff: sky/specs/style-guide.md

Issue 1176763006: Sky Style Guide. (Closed) Base URL: https://github.com/domokit/mojo.git@master
Patch Set: Created 5 years, 6 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « no previous file | no next file » | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
(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.
OLDNEW
« no previous file with comments | « no previous file | no next file » | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698