From c4501f2202df7fcba72568199f7bff80cbf4c214 Mon Sep 17 00:00:00 2001 From: Hixie Date: Thu, 25 Jun 2015 10:13:56 -0700 Subject: [PATCH] Give rationale for style guide, suggest using more concise code when doing so doesn't harm readability. TBR=abarth Review URL: https://codereview.chromium.org/1209003002. --- specs/style-guide.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/specs/style-guide.md b/specs/style-guide.md index 3fa309c04..e71ad8406 100644 --- a/specs/style-guide.md +++ b/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); +> ``` +> ...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. -- GitLab