Dart efectivo

Identifiers

• DO nombra los tipos usando UpperCamelCase.
• DO nombra las extensiones usando UpperCamelCase.
• DO nombra paquetes, directorios y archivos fuente usando lowercase_with_underscores.
• DO nombra los prefijos de importación usando lowercase_with_underscores.
• DO nombra otros identificadores usando lowerCamelCase.
• PREFER usar lowerCamelCase para nombres de constantes.
• DO escribe con mayúsculas los acrónimos y abreviaturas de más de dos letras como palabras.
• PREFER usar comodines para parámetros de callback no utilizados.
• DON'T uses un guion bajo al principio para identificadores que no son privados.
• DON'T uses letras de prefijo.
• DON'T nombres explícitamente las bibliotecas.

Ordering

• DO coloca las importaciones dart: antes de otras importaciones.
• DO coloca las importaciones package: antes de las importaciones relativas.
• DO especifica las exportaciones en una sección separada después de todas las importaciones.
• DO ordena las secciones alfabéticamente.

Formatting

• DO formatea tu código usando dart format.
• CONSIDERA cambiar tu código para que sea más amigable con el formateador.
• PREFER líneas de 80 caracteres o menos.
• DO usa llaves para todas las declaraciones de control de flujo.

Comments

• DO formatea los comentarios como oraciones.
• DON'T uses comentarios de bloque para documentación.

Doc comments

• DO usa comentarios de documentación /// para documentar miembros y tipos.
• PREFER escribir comentarios de documentación para APIs públicas.
• CONSIDERA escribir un comentario de documentación a nivel de biblioteca.
• CONSIDERA escribir comentarios de documentación para APIs privadas.
• DO comienza los comentarios de documentación con un resumen de una sola oración.
• DO separa la primera oración de un comentario de documentación en su propio párrafo.
• EVITA la redundancia con el contexto circundante.
• PREFER comenzar los comentarios de una función o método con verbos en tercera persona si su propósito principal es un efecto secundario.
• PREFER comenzar un comentario de variable o propiedad no booleana con una frase nominal.
• PREFER comenzar un comentario de variable o propiedad booleana con "Si" seguido de una frase nominal o gerundio.
• PREFER una frase nominal o frase verbal no imperativa para una función o método si devolver un valor es su propósito principal.
• DON'T escribas documentación tanto para el getter como para el setter de una propiedad.
• PREFER comenzar los comentarios de biblioteca o tipo con frases nominales.
• CONSIDERA incluir ejemplos de código en los comentarios de documentación.
• DO usa corchetes en los comentarios de documentación para referirse a identificadores en alcance.
• DO usa prosa para explicar parámetros, valores de retorno y excepciones.
• DO coloca los comentarios de documentación antes de las anotaciones de metadatos.

Markdown

• EVITA usar markdown excesivamente.
• EVITA usar HTML para formato.
• PREFER cercas de comillas invertidas para bloques de código.

Writing

• PREFER brevedad.
• EVITA abreviaturas y acrónimos a menos que sean obvios.
• PREFER usar "this" en lugar de "the" para referirse a la instancia de un miembro.

Libraries

• DO usa cadenas en directivas part of.
• DON'T importes bibliotecas que están dentro del directorio src de otro paquete.
• DON'T permitas que una ruta de importación entre o salga de lib.
• PREFER rutas de importación relativas.

Null

• DON'T inicialices explícitamente variables a null.
• DON'T uses un valor predeterminado explícito de null.
• DON'T uses true o false en operaciones de igualdad.
• EVITA variables late si necesitas verificar si están inicializadas.
• CONSIDERA la promoción de tipos o patrones de verificación de nulos para usar tipos anulables.

Strings

• DO usa cadenas adyacentes para concatenar literales de cadena.
• PREFER usar interpolación para componer cadenas y valores.
• EVITA usar llaves en la interpolación cuando no sea necesario.

Collections

• DO usa literales de colección cuando sea posible.
• DON'T uses .length para ver si una colección está vacía.
• EVITA usar Iterable.forEach() con un literal de función.
• DON'T uses List.from() a menos que tengas la intención de cambiar el tipo del resultado.
• DO usa whereType() para filtrar una colección por tipo.
• DON'T uses cast() cuando una operación cercana servirá.
• EVITA usar cast().

Functions

• DO usa una declaración de función para vincular una función a un nombre.
• DON'T crees una lambda cuando un tear-off servirá.

Variables

• DO sigue una regla consistente para var y final en variables locales.
• EVITA almacenar lo que puedes calcular.

Members

• DON'T envuelvas un campo en un getter y setter innecesariamente.
• PREFER usar un campo final para hacer una propiedad de solo lectura.
• CONSIDERA usar => para miembros simples.
• DON'T uses this. excepto para redirigir a un constructor con nombre o para evitar sombreado.
• DO inicializa campos en su declaración cuando sea posible.

Constructors

• DO usa parámetros de inicialización cuando sea posible.
• DON'T uses late cuando una lista de inicializadores de constructor servirá.
• DO usa ; en lugar de {} para cuerpos de constructor vacíos.
• DON'T uses new.
• DON'T uses const redundante.

Error handling

• EVITA catches sin cláusulas on.
• DON'T descartes errores de catches sin cláusulas on.
• DO lanza objetos que implementan Error solo para errores programáticos.
• DON'T catch explícitamente Error o tipos que lo implementan.
• DO usa rethrow para relanzar una excepción capturada.

Asynchrony

• PREFER async/await sobre usar futures sin procesar.
• DON'T uses async cuando no tiene ningún efecto útil.
• CONSIDERA usar métodos de orden superior para transformar un stream.
• EVITA usar Completer directamente.
• DO prueba por Future<T> al desambiguar un FutureOr<T> cuyo argumento de tipo podría ser Object.

Names

• DO usa términos consistentemente.
• EVITA abreviaturas.
• PREFER poner el sustantivo más descriptivo al final.
• CONSIDERA hacer que el código se lea como una oración.
• PREFER una frase nominal para una propiedad o variable no booleana.
• PREFER una frase verbal no imperativa para una propiedad o variable booleana.
• CONSIDERA omitir el verbo para un parámetro booleano con nombre parameter.
• PREFER el nombre "positivo" para una propiedad o variable booleana.
• PREFER una frase verbal imperativa para una función o método cuyo propósito principal es un efecto secundario.
• PREFER una frase nominal o frase verbal no imperativa para una función o método si devolver un valor es su propósito principal.
• CONSIDERA una frase verbal imperativa para una función o método si quieres llamar la atención sobre el trabajo que realiza.
• EVITA comenzar un nombre de función o método con get.
• PREFER nombrar un método to___() si copia el estado del objeto a un nuevo objeto.
• PREFER nombrar un método as___() si devuelve una representación diferente respaldada por el objeto original.
• EVITA describir los parámetros en el nombre de la función o método.
• DO sigue las convenciones mnemotécnicas existentes al nombrar parámetros de tipo.

Libraries

• PREFER hacer que las declaraciones sean privadas.
• CONSIDERA declarar múltiples clases en la misma biblioteca.

Classes and mixins

• EVITA definir una clase abstracta de un solo miembro cuando una función simple servirá.
• EVITA definir una clase que contiene solo miembros estáticos.
• EVITA extender una clase que no está destinada a ser subclaseada.
• DO usa modificadores de clase para controlar si tu clase puede ser extendida.
• EVITA implementar una clase que no está destinada a ser una interfaz.
• DO usa modificadores de clase para controlar si tu clase puede ser una interfaz.
• PREFER definir un mixin puro o clase pura en lugar de una clase mixin.

Constructors

• CONSIDERA hacer tu constructor const si la clase lo soporta.

Members

• PREFER hacer que los campos y las variables de nivel superior sean final.
• DO usa getters para operaciones que conceptualmente acceden a propiedades.
• DO usa setters para operaciones que conceptualmente cambian propiedades.
• DON'T definas un setter sin un getter correspondiente.
• EVITA usar pruebas de tipo en tiempo de ejecución para falsificar la sobrecarga.
• EVITA campos late final públicos sin inicializadores.
• EVITA devolver tipos Future, Stream y colección anulables.
• EVITA devolver this desde métodos solo para habilitar una interfaz fluida.

Types

• DO anota el tipo de variables sin inicializadores.
• DO anota el tipo de campos y variables de nivel superior si el tipo no es obvio.
• DON'T anotes redundante el tipo de variables locales inicializadas.
• DO anota los tipos de retorno en las declaraciones de función.
• DO anota los tipos de parámetros en las declaraciones de función.
• DON'T anotes los tipos de parámetros inferidos en expresiones de función.
• DON'T anotes el tipo de parámetros de inicialización.
• DO escribe argumentos de tipo en invocaciones genéricas que no se infieren.
• DON'T escribas argumentos de tipo en invocaciones genéricas que se infieren.
• EVITA escribir tipos genéricos incompletos.
• DO anota con dynamic en lugar de dejar que la inferencia falle.
• PREFER firmas en anotaciones de tipo de función.
• DON'T especifiques un tipo de retorno para un setter.
• DON'T uses la sintaxis typedef heredada.
• PREFER tipos de función en línea sobre typedefs.
• PREFER usar sintaxis de tipo de función para parámetros.
• EVITA usar dynamic a menos que quieras deshabilitar la verificación estática.
• DO usa Future<void> como el tipo de retorno de miembros asíncronos que no producen valores.
• EVITA usar FutureOr<T> como un tipo de retorno.

Parameters

• EVITA parámetros booleanos posicionales.
• EVITA parámetros posicionales opcionales si el usuario puede querer omitir parámetros anteriores.
• EVITA parámetros obligatorios que acepten un valor especial de "sin argumento".
• DO usa parámetros de inicio inclusivo y final exclusivo para aceptar un rango.

Equality

• DO sobrescribe hashCode si sobrescribes ==.
• DO haz que tu operador == obedezca las reglas matemáticas de igualdad.
• EVITA definir igualdad personalizada para clases mutables.
• DON'T hagas que el parámetro de == sea anulable.