¿Por qué no los dos?
En primer lugar, "descriptivo" y "detallado" no son lo mismo. Por ejemplo, si está escribiendo un bucle bastante local, ies un nombre de variable muy bueno para la variable del bucle; current_iteration_index, aunque podría decirse que es más descriptivo y definitivamente más detallado, es mucho peor y no agrega ninguna información, porque el uso de icomo una variable de bucle es bastante universalmente aceptado, y no hay otro significado ique eso.
Los buenos nombres de variables son descriptivos, ya que un programador familiarizado con el idioma del lenguaje y las convenciones de la base de código puede adivinar fácilmente cuál es su papel, pero también son lo suficientemente concisos como para mantener las cosas compactas.
El límite de 80 caracteres, aunque originalmente era una consecuencia de las limitaciones técnicas de los terminales de texto de la década de 1970, todavía es valorado por muchos hoy en día, y aunque todavía hay razones técnicas (longitudes máximas de línea en algunos protocolos de red, especialmente relacionados con el correo electrónico), Las razones más convincentes son las psicológicas y sociales. Resulta que las longitudes de línea alrededor de la marca de 66 caracteres hacen la experiencia de lectura más cómoda para la prosa en lenguaje natural (el tamaño de la fuente curiosamente no hace mucha diferencia y, en consecuencia, tampoco lo hace la pantalla o el tamaño del papel); Los límites de línea de 80 caracteres están bastante cerca de eso, pero dado que la mayor parte de un fragmento de código típico suele estar sangrado al menos uno o dos niveles (lo que significa entre 4 y 16 caracteres, dependiendo de la configuración de sangría),
Otro efecto de apegarse a las líneas de 80 caracteres es que es un buen indicador de cuándo las cosas son demasiado complicadas. Las líneas tan largas generalmente son causadas por uno de los siguientes:
- Funciones con una larga lista de argumentos; Esto no es algo agradable, ya que impiden la legibilidad y pueden causar fácilmente errores sutiles, por ejemplo, cuando las personas intercambian el orden de los argumentos de una manera que el compilador no detecta.
- Expresiones complejas, a menudo encontradas en condicionales (por ejemplo
if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); esto también suele ser bastante difícil de descifrar, y el código debe reescribirse en algo más estructurado. Lo más probable es que la expresión haga demasiado y debe factorizarse en un método o función.
- Literales largos utilizados en llamadas a funciones o expresiones, por ejemplo
print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));. Mueve el literal a una variable o constante; aún puede exceder la longitud de la línea, pero si lo hace de manera consistente, el lector puede ignorar al menos con seguridad la parte invisible de la línea, suponiendo que solo siga el resto del literal. O mejor aún, mueva los literales fuera del código a un almacén de datos externo (archivo, base de datos, lo que sea).
- Declaraciones profundamente anidadas, por ejemplo, seis niveles de
ifdeclaraciones en un método de clase (son 32 columnas de sangría para configuraciones típicas). Una vez más, la anidación profunda crea un código complejo y difícil de leer, y debe evitarse como la peste: en pocas palabras, la anidación profunda desborda la pila del cerebro humano mientras lee.
Todos estos son, en última instancia, síntomas de cosas que preferiría no tener en su base de código a largo plazo, y hacer cumplir los límites de 80 caracteres es una manera simple y agradable que ayuda a mantener baja la complejidad y la legibilidad. (Eso no quiere decir que no pueda escribir código perfectamente ilegible en 80 columnas: los diversos concursos de código de algo ofuscado son un claro contraejemplo).