Frecuentemente escucho estas dos valiosas prácticas de programación: (1) las líneas de código deben tener 80 caracteres o menos y (2) usar nombres descriptivos para variables, métodos, clases, etc. Sin embargo, entiendo el razonamiento de estas dos palabras de consejo. , a menudo parecen ser compensaciones entre ellos. Si mantengo mi código por debajo de 80 caracteres / línea, termino usando nombres menos descriptivos (especialmente en Python en el que cada sangría cuenta como 4 caracteres) pero si uso nombres más descriptivos, termino con líneas de más de 80 caracteres.

Entonces, mi pregunta es cuál de estos dos consejos es más importante cumplir si se debe hacer la elección. Me pregunto esto como un programador independiente (aficionado), pero lo más importante desde la perspectiva de un ingeniero de software que trabaja para una empresa más grande.

Mantenga pocas sangrías, sus nombres descriptivos, y no tenga miedo de romper una línea.

Mantenga sus sangrías pocas.

A menudo, cuando me encuentro en una lucha entre sangrías y nombres descriptivos, doy un paso atrás y miro mi nivel de sangría. Si sangra más de 3 o 4 niveles (2 niveles es automático e inevitable en muchos casos. Lea: definición de método de clase), es posible que desee reestructurar su código, abstrayendo la funcionalidad a una función o método.

Tus nombres descriptivos

Siempre debe mantener sus nombres descriptivos. Los nombres descriptivos crean código autodocumentado. Puede intentar acortar los nombres en algunos casos, pero la legibilidad es lo primero.

No tengas miedo de romper una línea

Mierda pasa. Si superas los 80 caracteres y no ves de ninguna manera para reclamar ningún espacio en la línea, divídelo. La mayoría de los idiomas no se preocupan por los saltos de línea, así que divídalos en múltiples. No solo elijas una ubicación aleatoria. Mantenga las cosas agrupadas lógicamente y sangra otro nivel cuando rompa la línea.

¿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).

La denominación descriptiva es MUCHO más importante. En la mayoría de las interfaces podemos desplazarnos para ver líneas más largas. En ningún caso el sistema puede ayudarlo a traducir variables y funciones mal nombradas.

80 caracteres por línea no es difícil de cumplir, incluso los nombres son largos porque hay muchas formas de dividir una sola línea de código largo en múltiples códigos cortos, por ejemplo, puedo dividir una declaración de condición en C en varias líneas para que quepan en menos de 40 caracteres,

if ( a == b || c == d  || d == e
    || c == e || c == a || c == k
    || c == l)

También puede dividir una línea de llamadas de funciones en varias líneas también.

Por lo tanto, ambas reglas de nomenclatura descriptiva y 80 líneas de caracteres no tienen contradicción, pueden coexistir para mejorar la legibilidad.

El límite 80 es algo que debería haberse incrementado hace mucho tiempo. Tenga en cuenta que este límite se utiliza desde la edad en que la longitud de cada identificador se limitaba a 8 caracteres y solo una fuente en la pantalla / impresora. No hay posibilidad de cambiar el tamaño de fuente.

Dios, tenemos diferentes pantallas y tecnología de impresión ahora. Tenemos lenguajes de programación muy diferentes. Ya no hay razón para usar 80 caracteres. Aumentarlo a 120 caracteres al menos.

Incluso entonces no debería ser un límite difícil. ¿Vas un personaje por encima de la línea? Bueno, no pasa nada!

Editar:

Respuestas detalladas sobre la historia del límite de 80 caracteres

Caracteres por línea en Wikipedia

Un estudio en la Universidad Estatal de Wichita descubrió que la CPL solo tenía pequeños efectos sobre la legibilidad, incluidos los factores de velocidad y comprensión. Sin embargo, cuando se les pidió preferencias, el 60% de los encuestados indicó una preferencia por las líneas más cortas (35 CPL) o más largas (95 CPL) utilizadas en el estudio. Al mismo tiempo, el 100% de los encuestados seleccionó una de estas cantidades como la menos deseable.