Reglas del linter
Detalles sobre el linter de Dart y sus reglas de estilo que puedes elegir.
Usa el linter de Dart para identificar posibles problemas en tu código Dart.
Puedes usar el linter a través de tu IDE
o con el comando dart analyze.
Para obtener información sobre cómo habilitar y deshabilitar reglas de linter individuales, consulta las
secciones de reglas individuales de la
documentación del analyzer.
Esta página enumera todas las reglas del linter, con detalles como cuándo podrías querer usar cada regla, qué patrones de código la activan y cómo podrías corregir tu código.
Sets
#Para evitar la necesidad de seleccionar individualmente reglas de linter compatibles, considera comenzar con un conjunto de reglas de linter, que proporcionan los siguientes paquetes:
- lints
-
Contiene dos conjuntos de reglas seleccionados por el equipo de Dart. Recomendamos usar al menos el conjunto de reglas
core, que se utiliza al calificar paquetes cargados en pub.dev. O, mejor aún, usa el conjunto de reglasrecommended, un superconjunto decoreque identifica problemas adicionales y exige estilo y formato. Si estás escribiendo código de Flutter, usa el conjunto de reglas en el paqueteflutter_lints, el cual se basa enlints.
- flutter_lints
-
Contiene el conjunto de reglas
flutter, que el equipo de Flutter te anima a usar en aplicaciones, paquetes y plugins de Flutter. Este conjunto de reglas es un superconjunto del conjuntorecommended, el cual a su vez es un superconjunto del conjuntocoreque determina parcialmente la puntuación de los paquetes cargados en pub.dev.
Para aprender cómo usar un conjunto de reglas específico, visita la documentación para habilitar y deshabilitar reglas de linter.
Para encontrar más conjuntos de reglas predefinidos,
consulta el tema #lints
en pub.dev.
Estado
#Cada regla tiene un estado o nivel de madurez:
- Estable
-
Estas reglas son seguras de usar y están verificadas como funcionales con las últimas versiones del lenguaje Dart. Todas las reglas se consideran estables a menos que estén marcadas como experimentales, deprecadas o eliminadas.
- Experimental
-
Estas reglas aún están bajo evaluación y es posible que nunca se estabilicen. Úsalas con precaución y reporta cualquier problema que encuentres.
- Deprecado
-
Estas reglas ya no se sugieren para su uso y podrían eliminarse en una futura versión de Dart.
- Eliminado
-
Estas reglas ya se han eliminado en la última versión estable de Dart.
Correcciones rápidas
#Algunas reglas se pueden corregir automáticamente mediante correcciones rápidas. Una corrección rápida es una edición automatizada orientada a solucionar el problema reportado por la regla del linter.
Si la regla tiene una corrección rápida,
se puede aplicar usando dart fix
o usando tu editor con soporte de Dart.
Para obtener más información, consulta Correcciones rápidas para problemas de análisis.
Reglas
#El siguiente es un índice de todas las reglas del linter y una breve descripción de su funcionalidad. Para obtener más información sobre una regla específica, haz clic en el botón Learn more en su tarjeta.
Para obtener una lista generada automáticamente que contenga todas las reglas del linter
en Dart 3.12.2,
consulta Todas las reglas del linter.
Separar la expresión de la estructura de control de su declaración.
Colocar los parámetros con nombre requeridos primero.
Especificar @required en parámetros con nombre sin valores predeterminados.
Evitar importaciones relativas para archivos en lib/.
Evitar anotar con dynamic cuando no sea necesario.
Evitar literales bool en expresiones condicionales.
Evitar definir una clase que contenga solo miembros estáticos.
Evitar llamadas a métodos o accesos a propiedades en un objetivo dynamic.
Evitar declaraciones vacías en las cláusulas else.
Evitar sobrecargar el operador == y hashCode en clases no marcadas como @immutable.
Evitar escapar comillas internas convirtiendo las comillas que las rodean.
Evitar inicializadores de campos en clases const.
Evitar el uso de forEach con un literal de función.
No inicializar variables explícitamente a null.
No declarar múltiples variables en una sola línea.
No comprobar null en operadores == personalizados.
Evitar importaciones relativas para archivos en lib/.
No renombrar parámetros de métodos sobreescritos.
Evitar tipos de retorno en setters.
Evitar retornar null desde miembros cuyo tipo de retorno sea bool, double, int o num.
Evitar retornar null para void.
Evitar retornar this desde métodos solo para habilitar una interfaz fluida.
Evitar sombrear (shadowing) parámetros de tipo.
Evitar una sola cascada en declaraciones de expresión.
Avoid
Evitar tipos como nombres de parámetros.
Evitar anotar tipos para parámetros de expresiones de función.
Evitar sobreescritos de campos final para retornar valores diferentes si se llaman múltiples veces.
Evitar definir parámetros no utilizados en constructores.
Evitar usar bibliotecas exclusivas para la web fuera de los paquetes de plugins web de Flutter.
Nombrar extensiones usando UpperCamelCase.
Cascada de invocaciones de métodos consecutivas en la misma referencia.
No convertir un valor anulable a un tipo no anulable.
Solo hacer referencia a identificadores dentro del alcance en comentarios de documentación.
Preferir usar lowerCamelCase para nombres de constantes.
Evitar el flujo de control en bloques finally.
SÍ usar llaves para todas las estructuras de control de flujo.
Adjuntar comentarios de documentación de la biblioteca a las directivas de la biblioteca.
Depender de los paquetes referenciados.
Evitar el uso de elementos obsoletos (deprecated) desde el paquete en el que están declarados.
SÍ hacer referencia a todas las propiedades públicas en métodos de depuración.
Adherirse a las convenciones de ordenamiento de directivas de la Guía de Effective Dart.
No debería haber llamadas que retornen un Future en funciones síncronas a menos que se asignen o se retornen.
Usar ; en lugar de {} para cuerpos de constructor vacíos.
Usar ; en lugar de {} para cuerpos de contenedor vacíos.
Definir cláusulas case para todas las constantes en clases de tipo enum.
Nombrar archivos fuente usando lowercase_with_underscores.
Usar el formato TODO de Flutter: // TODO(username): mensaje, https://URL-to-issue.
Sobreescribir siempre hashCode si se sobreescribe ==.
No importar archivos de implementación de otro paquete.
Hacer tear-off explícito de métodos call cuando se use un objeto como Function.
Inicializar el campo en el inicializador del campo.
Usar expresiones case que sean válidas en Dart 3.0.
Evitar pruebas de tipo en tiempo de ejecución con tipos de interoperabilidad JS donde el resultado puede no ser consistente con la plataforma.
Las condiciones no deberían evaluarse incondicionalmente a true o a false.
Unir la declaración return con la asignación cuando sea posible.
Comenzar las cadenas multilínea con una nueva línea.
Adjuntar anotaciones de biblioteca a directivas de biblioteca.
Usar lowercase_with_underscores al especificar un prefijo de biblioteca.
Evitar el uso de tipos privados en APIs públicas.
Falta un lenguaje especificado en un bloque de código.
Falta espacio en blanco entre cadenas adyacentes.
No usar más de un caso con el mismo valor.
Evitar guiones bajos iniciales para prefijos de biblioteca.
Evitar guiones bajos iniciales para identificadores locales.
No comparar expresiones booleanas con literales booleanos.
No usar parámetros o variables comodín (wildcard).
Nombrar identificadores no constantes usando lowerCamelCase.
No usar la comprobación de null en un parámetro de tipo potencialmente anulable.
No pasar null como argumento donde se espera una clausura (closure).
Omitir anotaciones de tipo obvias para variables locales.
Omitir anotaciones de tipo obvias para variables de nivel superior y estáticas.
Evitar definir una clase abstracta de un solo miembro cuando una función simple sea suficiente.
Proporcionar comentarios de documentación para todas las APIs públicas.
Usar lowercase_with_underscores para nombres de paquetes.
Prefijar los nombres de las bibliotecas con el nombre del paquete y una ruta separada por puntos.
Usar cadenas adyacentes para concatenar literales de cadena.
Preferir colocar aserciones (asserts) en listas de inicializadores.
Preferir usar un booleano como condición de la aserción.
Usar literales de colección cuando sea posible.
Preferir el uso de ??= en lugar de comprobar si es null.
Preferir declarar constructores const en clases @immutable.
Preferir literales const como parámetros de constructores en clases @immutable.
Preferir definir constructores en lugar de métodos estáticos para crear instancias.
Usar contains para instancias de List y String.
Preferir comillas dobles donde no requieran secuencias de escape.
Usar = para separar un parámetro con nombre de su valor predeterminado.
Usar => para miembros cortos cuyo cuerpo sea una sola declaración return.
Preferir final en la variable del bucle for-each si la referencia no se reasigna.
Preferir final para declaraciones de variables si no se reasignan.
Preferir final para declaraciones de parámetros si no se reasignan.
Preferir elementos for al construir mapas a partir de iterables.
Usar forEach solo para aplicar una función a todos los elementos.
Usar una declaración de función para vincular una función a un nombre.
Preferir alias de tipo de función genérica.
Preferir elementos if sobre expresiones condicionales cuando sea posible.
Usar parámetros formales de inicialización cuando sea posible.
Declarar elementos de lista en línea cuando sea posible.
Usar interpolación para componer cadenas y valores.
Usar isNotEmpty para Iterables y Maps.
Preferir el uso de whereType en iterables.
Preferir llamadas a métodos null-aware (sensibles a null).
Preferir el uso de operadores null-aware (sensibles a null).
Preferir importaciones relativas para archivos en lib/.
Solo usar comillas dobles para cadenas que contengan comillas simples.
Usar colecciones spread (propagación) cuando sea posible.
Preferir tipar las variables y campos no inicializados.
No usar el tipo Null, a menos que tengas la seguridad de que no quieres void.
Proporcionar un mensaje de deprecación, a través de @Deprecated("mensaje").
El getter de la propiedad se retorna a sí mismo recursivamente.
Deprecación en versión principal (major version).
Usar comas flotantes (trailing commas) para todas las listas de parámetros y de argumentos.
Evitar nombres de miembros innecesarios en patrones de variables.
Usar los constructores con nombre shrink y expand de SizedBox.
Preferir usar /// para comentarios de documentación.
Ordenar las propiedades secundarias (child) al final en las creaciones de instancias de widgets.
Ordenar las declaraciones de constructores antes que otros miembros.
Ordenar las declaraciones de constructores sin nombre primero.
Especificar anotaciones de tipo no obvias para variables locales.
Especificar anotaciones de tipo no obvias para variables estáticas y de nivel superior.
Especificar anotaciones de tipo.
Colocar la llamada a super al final en la lista de inicialización de un constructor.
Ajustar el tipo del parámetro formal de inicialización.
No anotar tipos en parámetros formales de inicialización.
No usar patrones constantes con literales de tipo.
Los resultados de Future en cuerpos de funciones async deben tener await o marcarse como
unawaited usando dart:async.
El uso de corchetes angulares en un comentario de documentación es tratado como HTML por Markdown.
Evitar el uso de llaves en la interpolación cuando no sea necesario.
No usar un const explícito en un constructor generativo de enum.
Nombre de constructor .new innecesario.
Evitar envolver campos en getters y setters solo para estar "seguro".
No especificar el modificador late cuando no sea necesario.
Evitar las directivas de biblioteca a menos que tengan comentarios de documentación o anotaciones.
No incluir un nombre de biblioteca en una declaración library.
Evita usar null en asignaciones que consideran null (null-aware).
Operador null-aware innecesario en una extensión sobre un tipo anulable.
Evitar el uso de null en operadores ??.
Usar un tipo no anulable para una variable final inicializada con un valor no anulable.
No sobreescribir un método para hacer una invocación al método super con los mismos parámetros.
Se pueden eliminar los cuerpos de constructor primario innecesarios.
Eliminar barras diagonales inversas (backslashes) innecesarias en las cadenas.
Interpolación de cadenas innecesaria.
No acceder a miembros con this a menos que se evite el ensombrecimiento (shadowing).
Uso de toList() innecesario en spreads (propagaciones).
No usar un nombre de tipo explícito en un constructor.
Se pueden eliminar los guiones bajos innecesarios.
Miembros de nivel superior inalcanzables en bibliotecas ejecutables.
Tipo inseguro: tiene una variable de tipo en una posición no covariante.
No usar el BuildContext a través de brechas (gaps) asíncronas.
Preferir un número entero hexadecimal de 8 dígitos (por ejemplo, 0xFFFFFFFF) para instanciar un Color.
Usar la sintaxis de tipo de función genérica para los parámetros.
Usar operadores ?? para convertir nulls a bools.
Preferir intValue.isOdd/isEven en lugar de verificar el resultado de % 2.
Usar late para miembros privados con un tipo no anulable.
Los elementos if que prueban nulidad se pueden reemplazar con elementos null-aware.
Usar rethrow para volver a lanzar una excepción capturada.
Usar un setter para operaciones que cambian conceptualmente una propiedad.
Usar cadenas en las directivas part of.
Usar parámetros super-initializer donde sea posible.
Comenzar el nombre del método con to/_to o as/_as si corresponde.
Evitar declarar parámetros con var y sin anotación de tipo.
A menos que se indique lo contrario, la documentación en este sitio refleja Dart 3.12.2. Página actualizada por última vez el 16-10-2025. Ver fuente oreportar un problema.