Regras do linter

Declare os tipos de retorno dos métodos.

Separe a expressão de controle do seu comando.

Coloque os parâmetros nomeados obrigatórios primeiro.

Especifique @required em parâmetros nomeados sem valores padrão.

Especifique anotações de tipo.

Evite imports relativos para arquivos em lib/.

Anote os membros sobrescritos.

Anote os membros redeclarados.

Retorno sem await.

Evite anotar com dynamic quando não for necessário.

Evite usar as.

Evite literais bool em expressões condicionais.

Evite catch sem cláusulas on.

Não capture explicitamente Error nem tipos que o implementem.

Evite definir uma classe que contenha apenas membros estáticos.

Evite verificações de double e int.

Evite chamadas de métodos ou acessos a propriedades em um alvo dynamic.

Evite comandos vazios em cláusulas else.

Evite sobrescrever operator == e hashCode em classes que não estão marcadas com @immutable.

Evite escapar aspas internas trocando as aspas que envolvem a string.

Evite inicializadores de campo em classes const.

Evite final nas declarações de parâmetros.

Evite usar forEach com um function literal.

Evite usar 'FutureOr' como tipo de um resultado.

Não implemente classes que sobrescrevem ==.

Não inicialize variáveis explicitamente com null.

Evite inteiros arredondados em JavaScript.

Não declare várias variáveis em uma única linha.

Não verifique null em operadores == personalizados.

Evite parâmetros booleanos posicionais.

Evite chamadas a print em código de produção.

Evite typedefs de funções privados.

Evite valores de argumento redundantes.

Evite imports relativos para arquivos em lib/.

Não renomeie parâmetros de métodos sobrescritos.

Evite tipos de retorno em setters.

Evite retornar null de membros cujo tipo de retorno é bool, double, int ou num.

Evite retornar null para Future.

Evite retornar null para void.

Evite retornar this de métodos apenas para habilitar uma interface fluente.

Evite setters sem getters.

Evite sombrear parâmetros de tipo.

Evite cascade simples em instruções de expressão.

Evite métodos assíncronos lentos de dart:io.

Evite .toString() em código de produção, pois os resultados podem ser minificados.

Evite tipos como nomes de parâmetros.

Evite anotar tipos em parâmetros de expressões de função.

Evite containers desnecessários.

Evite sobrescrever um campo final para retornar valores diferentes se for chamado várias vezes.

Evite definir parâmetros não utilizados em construtores.

Evite funções async que retornam void.

Evite usar bibliotecas exclusivas da web fora dos pacotes de plugin web do Flutter.

Use await apenas em futures.

Nomeie extensions usando UpperCamelCase.

Nomeie tipos usando UpperCamelCase.

Cancele instâncias de StreamSubscription do dart:async.

Encadeie chamadas consecutivas de método na mesma referência.

Não converta (cast) um valor anulável para um tipo não anulável.

Feche instâncias de Sink do dart:core.

Invocação de vários métodos de coleção com argumentos de tipos não relacionados.

Ordene os nomes dos combinators em ordem alfabética.

Referencie apenas identificadores no escopo em comentários de documentação.

Import condicional ausente.

Prefira usar lowerCamelCase para nomes de constantes.

Evite controle de fluxo em blocos finally.

FAÇA usar chaves em todas as estruturas de controle de fluxo.

Anexe comentários de documentação de biblioteca às diretivas library.

Dependa dos pacotes referenciados.

Anotação deprecated ausente.

Evite usar elementos descontinuados dentro do pacote em que são declarados.

FAÇA referenciar todas as propriedades públicas em métodos de debug.

Siga as convenções de ordenação de diretivas do Guia Effective Dart.

Não deve haver chamadas que retornam Future em funções síncronas, a menos que sejam atribuídas ou retornadas.

Não use variáveis de ambiente declaradas.

Documente os comentários de ignore.

Evite blocos catch vazios.

Use ; em vez de {} para corpos de construtores vazios.

Use ; em vez de {} para corpos de contêineres vazios.

Evite instruções vazias.

Use null safety sólido.

Coloque uma única quebra de linha no fim do arquivo.

Defina cláusulas case para todas as constantes em tipos semelhantes a enum.

Nomeie arquivos-fonte usando lowercase_with_underscores.

Use o formato de TODO do Flutter: // TODO(username): mensagem, https://URL-da-issue.

Para valores síncronos, Future.syncValue tem melhor desempenho.

Sempre sobrescreva hashCode ao sobrescrever ==.

Não importe arquivos de implementação de outro pacote.

Faça tear-off explícito de métodos call ao usar um objeto como Function.

Não reabra classes implicitamente.

Inicialize o campo no inicializador do próprio campo.

Use expressões case válidas no Dart 3.0.

Evite testes de tipo em tempo de execução com tipos de interop JS quando o resultado pode não ser consistente entre plataformas.

As condições não devem avaliar incondicionalmente para true ou para false.

Chamada de Iterable<E>.contains com referências de tipos não relacionados.

Junte a instrução return com a atribuição quando possível.

Comece strings multilinha com uma quebra de linha.

Anexe anotações de biblioteca às diretivas de biblioteca.

Nomeie bibliotecas usando lowercase_with_underscores.

Use lowercase_with_underscores ao especificar um prefixo de biblioteca.

Evite usar tipos privados em APIs públicas.

Evite linhas com mais de 80 caracteres.

Chamada de remove com referências de tipos não relacionados.

Expressão booleana composta apenas por literais.

Use nomes de super parâmetros correspondentes.

Widgets de design devem ser importados dos pacotes Material ou Cupertino.

Um bloco de código não tem a linguagem especificada.

Falta de espaço em branco entre strings adjacentes.

Não use strings adjacentes em lista.

Sem casos default.

Não use mais de um case com o mesmo valor.

Evite conversões implícitas a partir de dynamic.

Evite sublinhados iniciais em prefixos de biblioteca.

Evite sublinhados iniciais em identificadores locais.

Não compare expressões booleanas com literais booleanos.

Não coloque nenhuma lógica em createState.

Evite tipos brutos.

Evite chamar toString() em runtimeType.

Não atribua uma variável a ela mesma.

Não use parâmetros ou variáveis curinga.

Nomeie identificadores não constantes usando lowerCamelCase.

Operações primitivas sem efeito.

Não use verificação de null em um parâmetro de tipo potencialmente anulável.

Não passe null como argumento onde se espera uma closure.

Omita anotações de tipo para variáveis locais.

Omita anotações de tipo óbvias para variáveis locais.

Omita anotações de tipo óbvias para variáveis de nível superior e estáticas.

Evite definir uma classe abstrata com um único membro quando uma função simples basta.

Lance apenas instâncias de classes que estendem Exception ou Error.

Não sobrescreva campos.

Forneça comentários de documentação para todas as APIs públicas.

Use lowercase_with_underscores para nomes de pacotes.

Prefixe os nomes de bibliotecas com o nome do pacote e um caminho separado por pontos.

Não reatribua referências a parâmetros de funções ou métodos.

Use strings adjacentes para concatenar literais de string.

Prefira colocar asserts em listas de inicializadores.

Prefira asserts com mensagem.

Prefira usar um booleano como condição do assert.

Use literais de coleção quando possível.

Prefira usar ??= em vez de testar por null.

Prefira const com construtores constantes.

Prefira declarar construtores const em classes @immutable.

Prefira const em vez de final nas declarações.

Prefira literais const como parâmetros de construtores em classes @immutable.

Prefira definir construtores em vez de métodos estáticos para criar instâncias.

Use contains para instâncias de List e String.

Prefira aspas duplas quando elas não exigirem sequências de escape.

Use = para separar um parâmetro nomeado do seu valor padrão.

Use => para membros curtos cujo corpo é uma única instrução return.

Campo privado poderia ser final.

Prefira final na variável do laço for-each se a referência não for reatribuída.

Prefira final nas declarações de variáveis se elas não forem reatribuídas.

Prefira final nas declarações de parâmetros se eles não forem reatribuídos.

Prefira elementos for ao construir mapas a partir de iteráveis.

Use forEach para aplicar uma função a todos os elementos.

Use uma declaração de função para vincular uma função a um nome.

Prefira aliases de tipo de função genéricos.

Prefira elementos if a expressões condicionais sempre que possível.

Prefira usar operadores ??.

Use parâmetros formais de inicialização quando possível.

Declare itens de lista inline sempre que possível.

Prefira literais int a literais double.

Use interpolação para compor strings e valores.

Use isEmpty para Iterable e Map.

Use isNotEmpty para Iterable e Map.

Prefira o operador is!.

Prefira usar whereType em iteráveis.

Prefira usar mixins.

Prefira chamadas de método com null-aware.

Prefira usar operadores null-aware.

Prefira imports relativos para arquivos em lib/.

Use aspas duplas apenas para strings que contenham aspas simples.

Use coleções com spread quando possível.

Prefira tipar variáveis e campos não inicializados.

Não use o tipo Null, a menos que tenha certeza de que não quer void.

Forneça uma mensagem de depreciação, via @Deprecated("message").

Documente todos os membros públicos.

O getter de propriedade retorna a si mesmo recursivamente.

Depreciação em versão principal.

Use vírgulas finais em todas as listas de parâmetros e de argumentos.

Use URLs seguras no pubspec.yaml.

Use caminhos de diretiva simples.

Evite nomes de membros desnecessários em padrões de variáveis.

SizedBox para espaços em branco.

Use os construtores nomeados shrink e expand de SizedBox.

Prefira usar /// para comentários de documentação.

Ordene as propriedades child por último nas criações de instâncias de widgets.

Ordene as declarações de construtores antes dos outros membros.

Ordene as dependências do pub em ordem alfabética.

Ordene primeiro as declarações de construtores sem nome.

Especifique anotações de tipo não óbvias para variáveis locais.

Especifique anotações de tipo não óbvias para variáveis de nível superior e estáticas.

Especifique anotações de tipo.

Coloque a chamada de super por último na lista de inicialização de um construtor.

Evite instruções switch sobre um 'Type'.

Teste o tipo do argumento em operator ==(Object other).

Evite throw em bloco finally.

Restrinja o tipo do parâmetro formal de inicialização.

Anote os tipos das APIs públicas.

Não anote o tipo de parâmetros formais de inicialização.

Não use padrões constantes com literais de tipo.

Resultados Future em corpos de funções async devem ter await ou ser marcados como unawaited usando dart:async.

O uso de colchetes angulares em um comentário de documentação é tratado como HTML pelo Markdown.

Sem await, sem async.

Palavra-chave await desnecessária no return.

Evite usar chaves na interpolação quando não forem necessárias.

Não use break explícitos quando um break já está implícito.

Evite a palavra-chave const.

Não use const explícito em um construtor generativo de enum.

Nome de construtor .new desnecessário.

Não use final para variáveis locais.

Evite encapsular campos em getters e setters só por "segurança".

Não ignore um código de diagnóstico que não é produzido.

Não crie uma lambda quando um tear-off basta.

Não especifique o modificador late quando ele não for necessário.

Evite diretivas de biblioteca, a menos que tenham comentários de documentação ou anotações.

Não tenha nome de biblioteca em uma declaração library.

Palavra-chave new desnecessária.

Evite null em atribuição null-aware.

Operador null-aware desnecessário em extensão sobre um tipo anulável.

Verificações de null desnecessárias.

Evite usar null nos operadores ??.

Use um tipo não anulável para uma variável final inicializada com um valor não anulável.

Não sobrescreva um método apenas para chamar o método da superclasse com os mesmos parâmetros.

Parênteses desnecessários podem ser removidos.

Corpos de construtor primário desnecessários podem ser removidos.

String raw desnecessária.

Evite usar instruções desnecessárias.

Remova barras invertidas desnecessárias em strings.

Interpolação de string desnecessária.

Não acesse membros com this, a menos que seja para evitar sombreamento.

Use 'this' diretamente em vez de atribuí-lo a uma variável local.

toList() desnecessário em spreads.

Não use um nome de tipo explícito em um construtor.

Uso desnecessário de 'unawaited'.

Sublinhados desnecessários podem ser removidos.

Membros de nível superior inalcançáveis em bibliotecas executáveis.

Invocação do operador de igualdade == com referências de tipos não relacionados.

Evite APIs de HTML inseguras.

Tipo inseguro: possui uma variável de tipo em uma posição não covariante.

Não use BuildContext através de lacunas assíncronas.

Use ColoredBox.

Use um parâmetro declarante.

Use DecoratedBox.

Use enums em vez de classes que se comportam como enums.

Prefira um inteiro hexadecimal de 8 dígitos (por exemplo, 0xFFFFFFFF) para instanciar um Color.

Use a sintaxe de tipo de função genérica para parâmetros.

Use operadores ?? para converter nulls em bools.

Prefira intValue.isOdd/isEven em vez de verificar o resultado de % 2.

Use key nos construtores de widgets.

Use late para membros privados com tipo não anulável.

Use constantes nomeadas predefinidas.

Elementos if que testam null podem ser substituídos por elementos null-aware.

Use string raw para evitar escapes.

Use rethrow para relançar uma exceção capturada.

Use um setter para operações que conceitualmente alteram uma propriedade.

Use buffers de string para compor strings.

Use string em diretivas part of.

Use parâmetros de inicializador de super sempre que possível.

Use o matcher throwsA em vez de fail().

Comece o nome do método com to/_to ou as/_as, quando aplicável.

Use divisão truncada.

Use sintaxe de expressão regular válida.

Evite declarar parâmetros com var e sem anotação de tipo.

Não atribua a void.