Give rationale for style guide, suggest using more concise code when doing so doesn't harm readabil…

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
index 3fa309c04daf689e4e0e69169981139e897d45ae..e71ad84061b45cd04ecf1063bc5a20870abe350e 100644
--- a/sky/specs/style-guide.md
+++ b/sky/specs/style-guide.md
@@ -3,6 +3,10 @@ Sky Style Guide
 
 In general, follow our [Design Principles](design.md) for all code.
 
+The primary goal of this style guide is to improve code readability so
+that everyone, whether reading the code for the first time or
+maintaining it for years, can quickly determine what the code does. A
+secondary goal is avoiding arguments when there are disagreements.
 
 Dart
 ----
@@ -83,6 +87,26 @@ 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.)
 
+If a flow control structure has just one statement, then don't use
+braces around it except where doing so would help readability or avoid
+the dangling-else problem. Keeping the code free of boilerplate or
+redundant punctuation keeps it concise and readable.
+
+> For example,
+> ```dart
+>   if (children != null)
+>     for (RenderBox child in children)
+>       add(child);

[abarth-chromium, 2015/06/25 17:17:12]

The usual Google style for this situation is to put a { } around a single
statement if that statement occupies more than one physical line.  For example,
this could would become:

if (children != null) {
  for (RenderBox child in children)
    add(child);
}

Because the body of the |if| takes up more than one physical line.

+> ```
+> ...rather than:
+> ```dart
+>   if (children != null) {
+>     for (RenderBox child in children) {
+>       add(child);
+>     }
+>   }
+> ```
+
 
 Use the most relevant constructor or method, when there are multiple
 options.