El analizador lee un archivo a la vez y reporta lo que puede probar con él. Cuatro revisiones no se pueden hacer así: cada una necesita varios archivos abiertos a la vez, o un juicio sobre para qué es un pedazo de código. Nadie las hace si no las haces tú.
No están escritas como reglas justo por eso. Una regla que nunca puede ejecutarse es una regla que no reporta nada, y una regla callada se lee como una regla que pasó.
Hazlas cuando escribas o revises código en el área que cubren, y cuando las hayas hecho, di que las revisaste. Una revisión hecha por una persona nunca se reporta como una pasada del analizador.
Reutiliza un componente antes de escribir uno
El markup duplicado se ve exactamente igual que el markup original, así que solo se encuentra mirando.
Antes de escribir una vista, busca entre los componentes del proyecto uno que ya dibuje lo que necesitas. Empieza por los componentes de diseño, si el proyecto los tiene: los que se llaman como <x-design::nombre>, que se buscan primero en la carpeta propia del producto y luego en la de la base. La carpeta del producto es su catálogo propio de componentes compuestos, planeado por /design-catalog, y un patrón de este producto vive ahí y no entre los de la base compartida. Cuando hayas escrito uno, busca sus clases distintivas en el resto de las vistas: el mismo bloque de tres líneas en dos archivos es un componente que nadie extrajo.
Ninguna revisión puede atrapar esto, porque desde dentro de un archivo la copia se ve igual que el original.
Deja el trabajo de una sola vez donde se ejecuta
Un método de modelo es vocabulario: algo que la aplicación le pide a un registro, desde donde sea, más de una vez. Un relleno de datos acotado no lo es. Corre una vez y no se vuelve a llamar, así que va dentro de la migración que lo ejecuta. Uno cuyo costo crece con los datos (un recorrido por filas, trabajo con archivos, llamadas externas) corre en la cola, como dice Heavy Data Work Goes Through the Queue en el estándar Laravel Migrations (get_standard).
Antes de agregar un método a un modelo, busca quién más lo llamaría. Si la respuesta es solo la migración, el job o el comando que estás escribiendo ahora, déjalo ahí.
El archivo solo no puede responder esto. El método está bien escrito de cualquier forma; lo que lo decide es si existe un segundo llamador en algún lugar del proyecto.
Cada observer atiende a su propio modelo
El observer de un padre puede escribir registros hijos. Lo que no debe hacer es ejecutar el comportamiento propio del hijo: un efecto causado por un cambio de estado del hijo le pertenece al observer del hijo.
Cuando el observer de un padre llama a un método de un modelo relacionado, abre ese método. Si hace algo más que escribir el registro —manda algo, recalcula algo, dispara algo más—, le pertenece al hijo.
Esto necesita dos archivos a la vez: el observer y el método que llama. Ninguno de los dos está mal por sí solo.
Una clase nombra lo que le pertenece
El nombre de una clase dice su propósito, y todo lo que hay dentro sirve a ese propósito. Una clase dueña del programa de referidos no guarda un método sobre facturas.
Lee los nombres de los métodos contra el nombre de la clase. Si no le responden, el código todavía no fue colocado, y una carpeta de clases de aplicación no es el hogar del código que no tiene un hogar obvio.
Esto es un juicio sobre la intención. Una máquina ve que el método está ahí; no ve que no pertenece.
Dónde caen estas junto a una ejecución
Una ejecución limpia quiere decir que el archivo pasó las reglas que le aplican, lo cual vale la pena y no es lo mismo que el código esté bien. Lee una ejecución por lo que prueba —eso está en Leer un hallazgo— y haz estas cuatro tú mismo en la misma pasada.
Por qué una regla sin revisión automática se queda fuera de los estándares, y qué pasa cuando una gana su revisión más adelante, está en Escribir una regla nueva.