• tl;dr
• Introduction
• Table of Contents
• Overview
• A word on designing APIs
• Philosophy
• Lazy programming
• Write Test, Find Bug
• Avoid duplicating state
• Getters feel faster than methods
• No synchronous slow work
• Layers
• Avoid interleaving multiple concepts together
• Avoid secret (or global) state
• Prefer general APIs, but use dedicated APIs where there is a reason
• Avoid the lowest common denominator
• Avoid APIs that encourage bad practices
• Avoid exposing API cliffs
• Avoid exposing API oceans
• Avoid heuristics and magic
• Solve real problems by literally solving a real problem
• Get early feedback when designing new APIs
• Start designing APIs from the closest point to the developer
• Only log actionable messages to the console
• Error messages should be useful
• Policies
• Plugin compatibility
• Workarounds
• Avoid abandonware
• Widget libraries follow the latest OEM behavior
• Code that is not copyrighted "The Flutter Authors"
• Documentation (dartdocs, javadocs, etc)
• Answer your own questions straight away
• Avoid useless documentation
• Writing prompts for good documentation
• Introduce terms as if every piece of documentation is the first the reader has ever seen
• Avoid empty prose
• Leave breadcrumbs in the comments
• Refactor the code when the documentation would be incomprehensible
• Canonical terminology
• Use correct grammar
• Use the passive voice; recommend, do not require; never say things are simple
• Provide sample code
• Provide full application samples.
• Provide illustrations, diagrams or screenshots
• Clearly mark deprecated APIs
• Use /// for public-quality private documentation
• Dartdoc templates and macros
• Dartdoc-specific requirements
• Coding patterns and catching bugs early
• Use asserts liberally to detect contract violations and verify invariants
• Prefer specialized functions, methods and constructors
• Minimize the visibility scope of constants
• Avoid using if chains or ?: or == with enum values
• Avoid using var and dynamic
• Avoid using library and part of.
• Avoid using extension.
• Avoid using FutureOr<T>
• Avoid using Expando
• Never check if a port is available before using it, never add timeouts, and other race conditions.
• Avoid mysterious and magical numbers that lack a clear derivation
• Have good hygiene when using temporary directories
• Perform dirty checks in setters
• Common boilerplates for operator == and hashCode
• Override toString
• Be explicit about dispose() and the object lifecycle
• Test APIs belong in the test frameworks
• Immutable classes should not have hidden state
• Avoid sync*/async*
• Naming
• Begin global constant names with prefix "k"
• Avoid abbreviations
• Avoid anonymous parameter names
• Naming rules for typedefs and function variables
• Spell words in identifiers and comments correctly
• Capitalize identifiers consistent with their spelling
• Avoid double negatives in APIs
• Prefer naming the argument to a setter value
• Qualify variables and methods used only for debugging
• Avoid naming undocumented libraries
• Comments
• Avoid checking in comments that ask questions
• Comment all // ignores
• Comment all test skips
• Comment empty closures to setState
• Formatting
• In defense of the extra work that hand-formatting entails
• Constructors come first in a class
• Order other class members in a way that makes sense
• Constructor syntax
• Prefer a maximum line length of 80 characters
• Indent multi-line argument and parameter lists by 2 characters
• If you have a newline after some opening punctuation, match it on the closing punctuation.
• Use a trailing comma for arguments, parameters, and list items, but only if they each have their own line.
• Prefer single quotes for strings
• Consider using ⇒ for short functions and methods
• Use ⇒ for inline callbacks that just return list or map literals
• Prefer single line for short collection-if and collection-for
• Put spread inside collection-if or collection-for on the same line
• Use braces for long functions and methods
• Separate the 'if' expression from its statement
• Align expressions
• Prefer += over ++
• Use double literals for double constants
• Conventions
• Expectations around potential crashes in the engine
• Features we expect every widget to implement
• Use of streams in Flutter framework code
• Packages
• Structure
• Import conventions
• Deciding where to put code