Práctica: aplica la rúbrica completa a una función real

Hasta aquí has visto los cuatro ejes por separado. Ahora toca lo difícil: aplicarlos todos a la vez, a una función que ya está escrita, que parece bien y que se ejecuta sin lanzar ni un error.

Esa es la situación real. Nadie te entrega código que explote: te entregan cuarenta líneas plausibles —de un compañero, de un repositorio heredado, de un asistente de IA— y una pregunta implícita: «¿lo apruebo?».

La función de esta lección resume las líneas de pedido de una tienda por categoría. Tiene exactamente tres defectos plantados, uno por eje:

• uno de corrección: devuelve números equivocados con los datos normales;
• uno de caso borde: se traga un dato ausente sin avisar;
• uno de complejidad accidental: no cambia el resultado, pero es justo lo que permitió que los otros dos pasaran desapercibidos.

Antes de seguir, un recordatorio de la rúbrica en una tabla:

El orden importa: un defecto de corrección invalida cualquier discusión de estilo, así que se revisa de arriba hacia abajo.

El ciclo que vas a practicar es este, y es el mismo que usarás el resto del curso:

El encargo

El equipo de operaciones pidió una función que resuma las líneas de pedido por categoría. Este es el contrato acordado —tu única fuente de verdad para decidir si el código está bien:

resumen_por_categoria(lineas) devuelve un diccionario categoría -> {lineas, unidades, ingresos, ticket_promedio} aplicando estas reglas:

• R1. Las líneas con estado == "cancelado" no cuentan para nada.
• R2. Las líneas sin cantidad válida (vacía o None) no se pueden valorar: tampoco cuentan.
• R3. ingresos = suma de precio_unitario * cantidad, redondeado a 2 decimales.
• R4. ticket_promedio = ingresos dividido entre las líneas contabilizadas de esa misma categoría, redondeado a 2 decimales.

Un contrato explícito es la mitad de una revisión. Sin él, «revisar» degenera en opinar sobre nombres de variables: no puedes declarar incorrecto un resultado si nadie escribió cuál era el correcto.

Y estos son los datos: ocho líneas de pedido de la tienda, tal cual salen del CSV que exporta el sistema de ventas (nota que cantidad viene como texto, que una fila la trae vacía y que un estado es None).

El código a revisar

Léelo entero antes de hacer nada más. No busques el bug todavía: primero entiende qué cree hacer.

Paso 1: predice antes de ejecutar

Esta es la parte que casi todo el mundo se salta y la que más rinde. Si ejecutas primero, tu cerebro acepta el resultado que ve y deja de comparar; si predices primero, cualquier diferencia te salta a la cara.

La salida se imprimirá con este formato, una línea por categoría y ordenadas alfabéticamente:

Categoria: lineas=N unidades=N ingresos=N.NN ticket=N.NN

Escribe tu predicción (en papel, en un comentario, donde sea) para estas tres preguntas antes de tocar la celda siguiente:

1. ¿Cuántas líneas contabiliza Audio? ¿Y Accesorios?
2. ¿Cuáles son los ingresos de Computo?
3. ¿Cuál es el ticket_promedio de Computo? Pista de sentido común: los tres pedidos de Computo valen 3890, 1290 y 3890, así que su promedio tiene que caer entre 1290 y 3890.

La tercera pregunta es una técnica de revisión en sí misma: antes de calcular nada, define el rango en el que el resultado puede caer. Un promedio nunca puede quedar fuera del mínimo y el máximo de los valores promediados. Si el número sale del rango, hay un bug, y lo sabes sin haber leído una sola línea de la implementación.

Ahora sí: completa la llamada y ejecuta.

Paso 2: la discrepancia

Esto es lo que realmente imprime:

Accesorios: lineas=2 unidades=6 ingresos=454.00 ticket=56.75
Audio: lineas=2 unidades=1 ingresos=189.90 ticket=23.74
Computo: lineas=3 unidades=3 ingresos=9070.00 ticket=1133.75

Antes de leer el diagnóstico, contesta estas tres preguntas mirando solo la salida y el contrato. Son la revisión de verdad; lo que viene después es la confirmación.

1. Audio dice lineas=2 pero unidades=1. ¿Cómo puede una categoría tener dos líneas contabilizadas y una sola unidad vendida?
2. Computo promedia pedidos de 3890, 1290 y 3890, y devuelve un ticket de 1133.75. Ese número está por debajo del pedido más barato. ¿Qué operación puede producir un promedio fuera del rango de sus propios valores?
3. Accesorios factura 454.00 en 2 líneas y Audio 189.90 en 1. Divide a mano: 227.00 y 189.90. ¿Qué relación tienen 56.75 y 23.74 con esos números? (Multiplica por 4 y por 8 y verás.)

La magnitud del desvío se ve mejor así:

Paso 3: diagnóstico, eje por eje

Eje 1 — Corrección: el divisor equivocado

"ticket_promedio": round(ingresos / len(lineas), 2),

lineas es el parámetro de la función: las ocho líneas del archivo completo, incluida la cancelada y las de las otras categorías. El contrato (R4) exige dividir entre las líneas contabilizadas de esa categoría, que la función ya tiene guardadas en contadas, dos líneas más arriba.

Por eso los tres tickets están divididos entre 8 en vez de entre 2, 1 y 3. Es el defecto más caro de los tres —contamina un número que alguien va a llevar a una reunión— y es invisible a simple vista porque len(lineas) es sintácticamente impecable y semánticamente plausible: hay una variable llamada lineas justo ahí.

Regla portátil: cuando revises un promedio, un porcentaje o una tasa, no leas la fórmula: pregunta en voz alta «¿el numerador y el denominador hablan del mismo conjunto?». Es el chequeo que más bugs de corrección atrapa por minuto invertido.

Eje 2 — Casos borde: el dato ausente convertido en cero

cantidad = int(linea["cantidad"] or 0)

ORD-1005 llegó con cantidad vacía: el sistema de ventas no sabe cuántas unidades se pidieron. Como "" es falsy, la expresión "" or 0 evalúa a 0, y la línea entra al resumen como una venta de cero unidades.

No hay excepción, no hay aviso, no hay None en la salida. Simplemente Audio pasa a tener lineas=2 y, cuando arregles el divisor, ese cero fantasma seguiría hundiendo el ticket promedio a la mitad. El contrato (R2) es explícito: una línea sin cantidad válida no se puede valorar y no cuenta.

Este patrón —or 0, or "", or [] sobre un dato de entrada— es uno de los más frecuentes en código generado automáticamente, porque hace que el programa «no falle». Pero no fallar y estar bien son cosas distintas: aquí el código convierte «no sé» en «cero», que es una afirmación que nadie hizo.

Regla portátil: desconfía de todo valor por defecto aplicado a datos de entrada. Pregunta siempre: ¿el ausente y el cero significan lo mismo en este dominio? Casi nunca.

Eje 4 — Complejidad accidental: el doble recorrido

La función recorre los datos una vez para descubrir las categorías y luego una vez completa por cada categoría para filtrar las que no son de esa categoría. Con tres categorías, eso son cuatro pasadas sobre los mismos datos y un continue cuyo único trabajo es descartar el 66 % de las filas.

El resultado no cambia: podrías dejarlo así y la salida sería idéntica. Pero mira lo que costó:

• introdujo la lista categorias, la variable categoria del bucle externo y un filtro por categoría que no aportan nada al problema;
• alejó contadas de donde se usa, y ese alejamiento es exactamente lo que hizo verosímil escribir len(lineas).

Aquí está la lección menos obvia de todo el módulo: la complejidad accidental no es un problema estético, es el escondite de los otros defectos. Cuanto más código sobra, más superficie hay donde un error plausible pasa por normal.

Un solo recorrido acumulando en un diccionario categoria -> acumulados hace lo mismo con la mitad de líneas, y tiene un efecto colateral bonito: si una categoría no tiene ninguna línea contabilizada, sencillamente no se crea, y la división del ticket nunca puede dividir entre cero. La simplificación elimina un caso borde en lugar de obligarte a defenderlo.

Resumen de la revisión

El comentario de revisión

Con el formato de la lección anterior —qué, por qué importa, qué sugieres— el comentario del defecto de complejidad quedaría así:

Sugerencia (no bloqueante) — resumen_por_categoria, bucle externo. La función hace una pasada para descubrir categorías y otra pasada completa por categoría, filtrando las filas ajenas. Un solo recorrido acumulando en un dict por categoría produce el mismo resultado con menos estado intermedio, y evita que el contador de líneas quede lejos de donde se usa (que es, de hecho, donde se coló el divisor equivocado del comentario anterior). Como bonus, si una categoría se queda sin líneas válidas simplemente no aparece, en vez de dividir entre cero.

Fíjate en dos cosas: está marcado como no bloqueante (no confundas «yo lo escribiría distinto» con «esto está mal») y conecta la sugerencia con una consecuencia concreta, no con un gusto personal. Un comentario de estilo sin consecuencia se ignora; uno con consecuencia se aplica.

Lo que la verificación automática NO ve

En un minuto vas a corregir la función y un verificador comparará su salida con la esperada. Ese verificador atrapa los defectos 1 y 2, y es estructuralmente incapaz de ver el 3: el doble recorrido produce exactamente la misma salida.

Por eso existen las revisiones humanas. Los tests defienden la corrección y los bordes; la claridad y la complejidad accidental solo las defiende alguien leyendo. Guarda esta idea: la retomamos en el módulo de tests, donde verás que un test verde tampoco demuestra que la corrección esté bien.

Para llevar

• Predecir antes de ejecutar convierte una salida cualquiera en una discrepancia, y una discrepancia es una pista.
• Acota el rango del resultado (mínimo, máximo, signo, orden de magnitud) antes de calcularlo: los bugs de corrección suelen delatarse por salirse del rango.
• Numerador y denominador tienen que hablar del mismo conjunto.
• Un valor por defecto sobre datos de entrada (or 0) casi siempre esconde un caso borde mal resuelto.
• El código que sobra es donde se esconden los defectos que sí importan.

Paso 4: corrige y verifica

Ahora te toca a ti. La celda trae la función tal cual, con sus tres defectos. Tu trabajo es dejarla cumpliendo el contrato R1–R4 para que imprima exactamente esto:

Accesorios: lineas=2 unidades=6 ingresos=454.00 ticket=227.00
Audio: lineas=1 unidades=1 ingresos=189.90 ticket=189.90
Computo: lineas=3 unidades=3 ingresos=9070.00 ticket=3023.33

Dos reglas del ejercicio:

• No toques PEDIDOS ni imprimir. Corregir los datos de entrada o el formato de salida para que «cuadre» es hacer trampa —y, en un equipo real, es cómo se rompen tres cosas más abajo.
• Ataca también el eje 4, aunque el verificador no lo vea: reescribe el cuerpo con un solo recorrido acumulando por categoría. Si solo parcheas los dos números, apruebas la verificación y suspendes la revisión.

Cuando la salida coincida, pulsa Verificar.