Sky Style Guide.

sky/specs/style-guide.md

Index: sky/specs/style-guide.md
diff --git a/sky/specs/style-guide.md b/sky/specs/style-guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..cd0d4121a2da717fd6806971bb830512f07fdd49
--- /dev/null
+++ b/sky/specs/style-guide.md
@@ -0,0 +1,78 @@
+Sky Style Guide

[Matt Perry, 2015/06/10 18:36:49]

Should mention near the top that this is specifically for dart code.

+===============
+
+Always use the Dart Analyzer. Do not check in code that increases the
+output of the analyzer unless you've filed a bug with the Dart team.
+
+Use assert()s liberally.
+
+
+Classes and Enums are named UpperCamelCase. Everything else (methods,
+fields, variables, constants, enum values, etc) is lowerCamelCase.
+Global double and string constants are prefixed with k. Prefer using a
+static const in a relevant class than using a global constant.
+
+Don't name your libraries (no ```library``` keyword). Name the files
+in ```lower_under_score.dart``` format.
+
+
+Class constructors and methods should be ordered in the order that
+their members will be used in an instance's typical lifecycle. In
+particular, this means constructors all come first in class
+declarations.
+
+The default (unnamed) constructor should come first, then the named
+constructors.
+
+Fields should come before the methods that manipulate them, if they
+are specific to a particular group of methods.
+
+> For example, RenderObject groups all the layout methods and layout
+> fields together, then all the paint methods and paint fields.
+
+Fields that aren't specific to a particular group of methods should
+come immediately after the constructors.
+
+Be consistent in the order of members. If a constructor lists a bunch
+of fields, then those fields should declared be in the same order, and
+any code that operates on all of them should operate on them in the
+same order (unless the order matters).
+
+
+All variables and arguments are typed; don't use "var", "dynamic", or
+"Object" in any case where you could figure out the actual type.
+Always specialise generic types where possible. Even for ```[]``` and
+```{}``` literals, include the types.
+
+Aim for a line length of 80 characters, but go over if breaking the
+line would make it less readable.
+
+Only use => when the result fits on a single line.
+
+When using ```{ }``` for an empty block of code, put a single space
+between the two braces.
+
+Use // and ///, not /* */ and /** */.
+
+Don't put the statement part of an "if" statement on the same line as
+the expression, even if it is short. (Doing so makes it unobvious that
+there is relevant code there. This is especially important for early
+returns.)
+
+
+Use the most relevant constructor or method, when there are multiple
+options.
+
+> For example,
+> ```dart
+>    new EdgeDims.symmetric(horizontal: 8.0);
+> ```
+> ...rather than:
+> ```dart
+>    new EdgeDims(0.0, 8.0, 0.0, 8.0);
+> ```
+
+
+In general, follow our [Design Principles](design.md) and the [Dart
+style guide](https://www.dartlang.org/articles/style-guide/) where
+doing so wouldn't contradict the above.