Dart Efetivo

Identificadores

• FAÇA nomear tipos usando UpperCamelCase.
• FAÇA nomear extensões usando UpperCamelCase.
• FAÇA nomear pacotes, diretórios e arquivos-fonte usando lowercase_with_underscores.
• FAÇA nomear prefixos de import usando lowercase_with_underscores.
• FAÇA nomear os demais identificadores usando lowerCamelCase.
• PREFIRA usar lowerCamelCase para nomes de constantes.
• FAÇA escrever com maiúscula siglas e abreviações com mais de duas letras, como palavras.
• PREFIRA usar curingas para parâmetros de callback não usados.
• NÃO use underscore inicial em identificadores que não são privados.
• NÃO use letras de prefixo.
• NÃO nomeie bibliotecas explicitamente.

Ordenação

• FAÇA colocar imports dart: antes dos outros imports.
• FAÇA colocar imports package: antes dos imports relativos.
• FAÇA especificar exports em uma seção separada, depois de todos os imports.
• FAÇA ordenar as seções em ordem alfabética.

Formatação

• FAÇA formatar seu código usando dart format.
• CONSIDERE mudar seu código para torná-lo mais amigável ao formatador.
• PREFIRA linhas com 80 caracteres ou menos.
• FAÇA usar chaves em todas as estruturas de controle de fluxo.

Comentários

• FAÇA formatar comentários como frases.
• NÃO usar comentários de bloco para documentação.

Comentários de documentação

• FAÇA usar comentários de documentação /// para documentar membros e tipos.
• PREFIRA escrever comentários de documentação para APIs públicas.
• CONSIDERE escrever um comentário de documentação no nível da biblioteca.
• CONSIDERE escrever comentários de documentação para APIs privadas.
• FAÇA começar comentários de documentação com um resumo de uma frase.
• FAÇA separar a primeira frase de um comentário de documentação em seu próprio parágrafo.
• EVITE redundância com o contexto ao redor.
• PREFIRA começar comentários de funções ou métodos com verbos na terceira pessoa se o propósito principal for um efeito colateral.
• PREFIRA começar o comentário de uma variável ou propriedade não booleana com um sintagma nominal.
• PREFIRA começar o comentário de uma variável ou propriedade booleana com "Whether" seguido de um sintagma nominal ou gerundial.
• PREFIRA um sintagma nominal ou verbal não imperativo para uma função ou método se retornar um valor for seu propósito principal.
• NÃO escrever documentação para o getter e o setter de uma propriedade.
• PREFIRA começar comentários de biblioteca ou de tipo com sintagmas nominais.
• CONSIDERE incluir exemplos de código em comentários de documentação.
• FAÇA usar colchetes em comentários de documentação para se referir a identificadores no escopo.
• FAÇA usar texto corrido para explicar parâmetros, valores de retorno e exceções.
• FAÇA colocar comentários de documentação antes das anotações de metadados.

Markdown

• EVITE usar markdown em excesso.
• EVITE usar HTML para formatação.
• PREFIRA cercas de crase para blocos de código.

Escrita

• PREFIRA concisão.
• EVITE abreviações e siglas, a menos que sejam óbvias.
• PREFIRA usar "this" em vez de "the" para se referir à instância de um membro.

Bibliotecas

• FAÇA usar strings em diretivas part of.
• NÃO importe bibliotecas que estão dentro do diretório src de outro pacote.
• NÃO permita que um caminho de import alcance dentro ou fora de lib.
• PREFIRA caminhos de import relativos.

Null

• NÃO inicialize variáveis explicitamente para null.
• NÃO use um valor padrão explícito de null.
• NÃO use true ou false em operações de igualdade.
• EVITE variáveis late se você precisar verificar se elas foram inicializadas.
• CONSIDERE promoção de tipo ou padrões de verificação de null para usar tipos nullable.

Strings

• FAÇA usar strings adjacentes para concatenar literais de string.
• PREFIRA usar interpolação para compor strings e valores.
• EVITE usar chaves na interpolação quando não forem necessárias.

Coleções

• FAÇA usar literais de coleção sempre que possível.
• NÃO use .length para verificar se uma coleção está vazia.
• EVITE usar Iterable.forEach() com um literal de função.
• NÃO use List.from() a menos que você pretenda mudar o tipo do resultado.
• FAÇA usar whereType() para filtrar uma coleção por tipo.
• NÃO use cast() quando uma operação próxima resolver.
• EVITE usar cast().

Funções

• FAÇA usar uma declaração de função para vincular uma função a um nome.
• NÃO crie uma lambda quando um tear-off resolver.

Variáveis

• FAÇA seguir uma regra consistente para var e final em variáveis locais.
• EVITE armazenar o que você pode calcular.

Membros

• NÃO envolva um campo em um getter e setter sem necessidade.
• PREFIRA usar um campo final para criar uma propriedade somente leitura.
• CONSIDERE usar => para membros simples.
• NÃO use this. exceto para redirecionar a um construtor nomeado ou para evitar sombreamento.
• FAÇA inicializar campos na sua declaração sempre que possível.

Construtores

• FAÇA usar parâmetros inicializadores sempre que possível.
• NÃO use late quando uma lista de inicializadores do construtor resolver.
• FAÇA usar ; em vez de {} para corpos de construtor vazios.
• PREFIRA usar a sintaxe concisa de construtores.
• NÃO use new.
• NÃO use const de forma redundante.

Tratamento de erros

• EVITE capturas sem cláusulas on.
• NÃO descarte erros em capturas sem cláusulas on.
• FAÇA lançar objetos que implementam Error apenas para erros de programação.
• NÃO capture explicitamente Error ou tipos que o implementam.
• FAÇA usar rethrow para relançar uma exceção capturada.

Assincronia

• PREFIRA async/await em vez de usar futures diretamente.
• NÃO use async quando ele não tem efeito útil.
• CONSIDERE usar métodos de ordem superior para transformar um stream.
• EVITE usar Completer diretamente.
• FAÇA testar Future<T> ao desambiguar um FutureOr<T> cujo argumento de tipo pode ser Object.

Nomes

• FAÇA usar termos consistentemente.
• EVITE abreviações.
• PREFIRA colocar o substantivo mais descritivo por último.
• CONSIDERE fazer o código ler como uma sentença.
• PREFIRA uma frase substantiva para uma propriedade ou variável não-booleana.
• PREFIRA uma frase verbal não-imperativa para uma propriedade ou variável booleana.
• CONSIDERE omitir o verbo para um parâmetro booleano nomeado.
• PREFIRA o nome "positivo" para uma propriedade ou variável booleana.
• PREFIRA uma frase verbal imperativa para uma função ou método cujo principal propósito é um efeito colateral.
• PREFIRA uma frase substantiva ou frase verbal não-imperativa para uma função ou método se retornar um valor é seu propósito principal.
• CONSIDERE uma frase verbal imperativa para uma função ou método se você quer chamar atenção para o trabalho que realiza.
• EVITE iniciar um nome de método com get.
• PREFIRA nomear um método to___() se ele copia o estado do objeto para um novo objeto.
• PREFIRA nomear um método as___() se ele retorna uma representação diferente apoiada pelo objeto original.
• EVITE descrever os parâmetros no nome da função ou método.
• FAÇA seguir as convenções mnemônicas existentes ao nomear parâmetros de tipo.

Bibliotecas

• PREFIRA tornar declarações privadas.
• CONSIDERE declarar múltiplas classes na mesma biblioteca.

Classes e mixins

• EVITE definir uma classe abstrata de um membro quando uma função simples serve.
• EVITE definir uma classe que contém apenas membros estáticos.
• EVITE estender uma classe que não é destinada a ser subclasse.
• FAÇA usar modificadores de classe para controlar se sua classe pode ser estendida.
• EVITE implementar uma classe que não é destinada a ser uma interface.
• FAÇA usar modificadores de classe para controlar se sua classe pode ser uma interface.
• PREFIRA definir um mixin puro ou class pura a um mixin class.

Construtores

• CONSIDERE tornar seu construtor const se a classe suporta isso.

Membros

• PREFIRA tornar campos e variáveis de nível superior final.
• FAÇA usar getters para operações que conceitualmente acessam propriedades.
• FAÇA usar setters para operações que conceitualmente mudam propriedades.
• NÃO defina um setter sem um getter correspondente.
• EVITE usar testes de tipo em tempo de execução para falsificar sobrecarga.
• EVITE campos late final públicos sem inicializadores.
• EVITE retornar tipos Future, Stream, e coleção anuláveis.
• EVITE retornar this de métodos apenas para habilitar uma interface fluente.

Tipos

• FAÇA anotar o tipo de variáveis sem inicializadores.
• FAÇA anotar o tipo de campos e variáveis de nível superior se o tipo não é óbvio.
• NÃO anote redundantemente o tipo de variáveis locais inicializadas.
• FAÇA anotar tipos de retorno em declarações de função.
• FAÇA anotar tipos de parâmetros em declarações de função.
• NÃO anote tipos de parâmetros inferidos em expressões de função.
• NÃO anote o tipo de formals inicializadores.
• FAÇA escrever argumentos de tipo em invocações genéricas que não são inferidas.
• NÃO escreva argumentos de tipo em invocações genéricas que são inferidas.
• EVITE escrever tipos genéricos incompletos.
• FAÇA anotar com dynamic em vez de deixar a inferência falhar.
• PREFIRA assinaturas em anotações de tipo de função.
• NÃO especifique um tipo de retorno para um setter.
• NÃO use a sintaxe typedef legada.
• PREFIRA tipos de função inline a typedefs.
• PREFIRA usar sintaxe de tipo de função para parâmetros.
• EVITE usar dynamic a menos que você queira desabilitar verificação estática.
• FAÇA usar Future<void> como tipo de retorno de membros assíncronos que não produzem valores.
• EVITE usar FutureOr<T> como tipo de retorno.

Parâmetros

• EVITE parâmetros booleanos posicionais.
• EVITE parâmetros posicionais opcionais se o usuário pode querer omitir parâmetros anteriores.
• EVITE parâmetros obrigatórios que aceitam um valor especial de "sem argumento".
• FAÇA usar parâmetros de início inclusivo e fim exclusivo para aceitar um intervalo.

Igualdade

• FAÇA sobrescrever hashCode se você sobrescrever ==.
• FAÇA seu operador == obedecer as regras matemáticas de igualdade.
• EVITE definir igualdade personalizada para classes mutáveis.
• NÃO torne o parâmetro para == anulável.