La guía de estilo de C++ de Google desaconseja explícitamente el uso de tipos sin signo. Es un criterio extendido, repetido en libros de texto y revisiones de código durante décadas. Un artículo técnico reciente lo cuestiona con argumentos aritméticos concretos y sostiene que la recomendación no solo es incorrecta la mayor parte del tiempo, sino que además incentiva código inseguro.
El argumento central es sencillo: la mayoría de los enteros en un programa nunca representan valores negativos. Los índices de arreglos y los contadores de bucles son el ejemplo más obvio. Usar `int64_t` donde bastaría `size_t` no es una decisión conservadora; es trasladar el problema a un rango numérico distinto sin resolverlo.
El bucle inverso, caso de prueba clásico
El ejemplo más citado contra los enteros sin signo es el bucle que debe contar hacia atrás e incluir el cero. La solución habitual es convertir el valor sin signo a uno con signo mediante un cast, lo que en C y C++ constituye una conversión de reducción que silencia advertencias legítimas e invoca comportamiento indefinido para valores grandes. El artículo señala que cualquier entrada igual o superior a `0x7ffffffffffffffff` provocaría un fallo en la mayoría de las aplicaciones.
La alternativa con entero sin signo aprovecha que el desbordamiento por debajo de cero (underflow) está bien definido en C y C++: el contador envuelve al valor máximo del tipo, que es mayor que `size`, por lo que la condición del bucle evalúa falso y la iteración se detiene de forma correcta. No hay cast, no hay comportamiento indefinido, y el caso de `size == 0` también funciona sin código adicional.
En Rust, el compilador convierte ese patrón en sintaxis aún más explícita mediante rangos con `.rev()`, eliminando la necesidad de razonar sobre el desbordamiento en absoluto.
La diferencia absoluta entre dos valores
Otro argumento frecuente es que calcular `abs(x - y)` es peligroso con enteros sin signo porque si `y > x` se produce underflow. El artículo responde que el problema existe igualmente con enteros con signo: `INT_MAX - INT_MIN` produce un resultado incorrecto incluso en lenguajes que definen el comportamiento de desbordamiento, y la versión segura requiere una guarda condicional de dos ramas que pocos programadores escriben en la práctica.
Con enteros sin signo, la solución es directa: `max(x, y) - min(x, y)`. Siempre devuelve la diferencia absoluta correcta, es autodocumentada y no requiere nombre de variable auxiliar.
Qué está en juego
El texto no es un manifiesto de nicho. Toca un principio de ingeniería con consecuencias medibles: las vulnerabilidades derivadas de desbordamiento de enteros con signo figuran de forma recurrente en los registros de CVE de proyectos de infraestructura crítica. La recomendación de «siempre usa con signo» no elimina esa clase de error; la desplaza hacia un territorio donde el comportamiento es indefinido en lugar de predecible.
Conviene mirar los incentivos. Las guías de estilo corporativas priorizan la legibilidad para el programador promedio, no la corrección aritmética en casos extremos. El resultado es una convención que se autoperpetúa: los programadores nuevos aprenden a evitar los enteros sin signo porque «son difíciles», sin llegar a entender por qué el desbordamiento sin signo es determinista mientras que el desbordamiento con signo, en C y C++, es terreno de compiladores que optimizan agresivamente bajo la suposición de que ese caso nunca ocurre.
El dato importa más que el ruido. Enseñar la aritmética modular como herramienta, en lugar de como amenaza, resuelve los casos de uso más comunes con código más corto y más correcto. La historia de los errores de seguridad en software de sistema sugiere que vale la pena reconsiderar el consenso.
