¿Cómo evitan los programadores las líneas de código de más de 80 caracteres?

80 caracteres (columnas) es una reliquia de tarjetas perforadas de 80 columnas y terminales CRT de 80 columnas x 25 líneas. Probablemente también hubo terminales de impresión limitados a 80 caracteres, pero no encontré ninguno cuando era un cachorro.

Cuando era un cachorro, la mayoría de los terminales de impresión eran DECWriter II, generalmente estaban cargados con papel de 132 columnas. Las impresoras lineales suelen imprimir 120 columnas.

Reliquias Legado,

La única razón técnica para tratar de ajustar el código dentro de un formato de 80 columnas en estos días es para que quepa dentro del tamaño predeterminado de “xterm” (ventanas de terminal), pero son redimensionables. Por lo general, reduzco el mío a alrededor de 100 columnas, a veces MUCHO más ancho.

Mantener el código dentro de un ancho de 80 columnas es una ayuda para la legibilidad (humana) del código, y eso es importante. La mayoría de los idiomas le permiten dividir las expresiones para que una declaración complicada pueda cubrir varias líneas. Cuando lo hago, se basa en lo que siento hace que el código sea más legible (y mantenible).

Si encuentro que el código está tan desplazado por un espacio en blanco que excede las 80 columnas (más o menos), consideraré colocar ese código en una función / procedimiento / subrutina separada. Esto también se aplica a las tablas de datos / constantes: la mayoría de los lenguajes me permitirán crear objetos con nombre y referirme a ellos desde otros objetos con nombre.

Dado que espero estar trabajando en el mismo código en 5 años (o más), la mantenibilidad es mi principal interés. Si solo fuera un codificador de persecución de ambulancias, me importaría mucho menos.

Personalmente no. El límite de 80 columnas se remonta a los dispositivos que utilizamos hace décadas. La tarjeta perforada de 80 columnas o la pantalla de visualización de 80 × 24 caracteres, dependiendo de su fondo. Las pantallas modernas le permiten trabajar perfectamente bien con líneas más largas.

Dicho esto, puedes tener líneas demasiado largas. No ayuda tener que seguir girando la cabeza para leer el código. Entonces uso un límite ad-hoc de 128 caracteres. Este no es un límite difícil, pero rara vez lo rompo.

Lo primero es mantener su sangría estándar razonable. Ocho espacios (una pestaña primitiva) es demasiado. Cuatro está bien, y estoy contento con dos.

El segundo, obviamente, es dividir líneas en puntos lógicos. Todos los idiomas que conozco están bastante contentos con los saltos de línea bastante arbitrarios. Estos generalmente se pueden organizar para que coincidan con las subsecciones lógicas de una línea.

Luego puede dividir una declaración compleja en varias declaraciones, generalmente asignando subexpresiones a una variable local. Un compilador decente factorizará la variable, por lo que no hay sobrecarga. Además, las cadenas comunes de prefijos se pueden factorizar a una variable de referencia.

A veces, las grandes expresiones son una pista para factorizar las subexpresiones en una función separada.

Luego está la cuestión de los nombres de variables y campos. El arte consiste en capturar el mayor significado en la menor cantidad de personajes. No existe una regla estricta y rápida, y elegiría errar, si es que debo errar, en la dirección de más tiempo pero más informativo. Pero a veces los nombres cortos son todo lo que necesita: no tenga miedo de usar una palabra corta si es adecuadamente expresiva.

Al encapsular la lógica. Pero sigo esa regla solo dependiendo del lenguaje de programación. Cuando escribo código en Go lang, a menudo uso más columnas que 80 por línea. Aquí hay dos capturas de pantalla de una biblioteca Ruby y una aplicación Elixir que escribí (en ese orden. Sé que la sintaxis es muy similar):

Verá si tengo algo que se puede excluir en alguna función privada, lo excluyo con algunos nombres adecuados. En el caso de Elixir, puede tener saltos de línea, por ejemplo, al usar el operador de tubería (|>). Personalmente me gusta la regla de los 80 caracteres. También te obliga a mantener el código al punto

Como generalización, una combinación de enojarse cuando el código es difícil de leer, y generalmente no necesita escribir largas líneas.

En la práctica, limitando la cantidad de trabajo que hace por línea, aclarando las cosas dividiéndolas, utilizando variables como current = en lugar de copiar cosas como array.getcurrent (). Getcurrent () media veces en una declaración if … Ese tipo de cosa.

Raramente tengo que usar varias líneas para decir lo mismo (bueno, nunca tienes que hacerlo), pero de vez en cuando presiono enter y lo presiono.

¿Cuándo dejaste de golpear a tu esposa?

Sí, muchos programadores evitan líneas de código más largas que el límite físico arbitrario de las 80 columnas de las tarjetas perforadas de Hollerith introducidas por primera vez en 1928, pero por alguna razón se permiten escribir todo tipo de caracteres (¡minúsculas!) Que no son compatibles con esos Muy mismas tarjetas perforadas. Honestamente, es una tontería. Las tarjetas anteriores tenían menos columnas, tan solo 30, y algunas solo podían admitir números.

Muchos, no todos, los terminales y pantallas tenían límites similares, pero muchos de ellos tenían otros límites, tan bajos como 40 caracteres. El ubicuo TTY 33 tenía una longitud de línea de 72. La mayoría de las impresoras de mainframe tenían 120 o 132 columnas.

Ninguno de estos límites se ha pegado, pero de alguna manera algunos programadores piensan que 80 es un límite mágico. No es.

Personalmente, me concentro en la legibilidad y no me preocupa la longitud de la línea. Si el código es más legible con líneas cortas, genial. Si el código es más legible con líneas largas, genial. La longitud de la línea en sí misma es irrelevante.

Mi respuesta más directa a la pregunta de “cómo evitan los programadores las líneas de código de más de 80 caracteres” es:

Sacrifican la legibilidad al dividir las declaraciones y los cálculos claros en varias líneas, al acortar los nombres de las variables únicamente para guardar caracteres, sangrar menos (prefiero 4 para la máxima legibilidad) y crear funciones innecesarias.

¡Evita las trampas! Si desea mantener el código más compacto, existen algunas técnicas que aumentan la legibilidad. Por ejemplo, uso variables de 1-3 caracteres para un solo propósito, variables altamente locales. La mayoría de los programadores usan índices de bucle de i y j. Yo uso x para un bucle que no es numérico (por ejemplo, x en StateNames). Usaré una abreviatura corta como sn para StateName en un lugar similar (por ejemplo, sn en StateNames). Cuanto más larga sea la función, menos probable es que use ese nombre. Saber que sn es un StateName para 5-10 líneas está bien, pero no está bien exigirle a alguien que lea su código que recuerde lo que significan muchos nombres cortos en todo su programa. Si se usa correctamente, esta técnica puede mejorar su código, no empeorarlo, y debe adoptar este enfoque con todo lo que hace.

Bueno, tocamos volver. Ok, en serio:

Estructura tu código para que no haya un nivel profundo de anidamiento. Si anida declaraciones de más de dos de profundidad, piense en lo que está haciendo y considere hacer cambios. De todos modos, no será fácil de leer.

Use suficientes pestañas para dejar una sangría clara, pero no más que eso. Más de cuatro espacios es probablemente demasiado.

Use convenciones de nomenclatura que resulten legibles, pero nombres más cortos. Por alguna razón, los programadores acostumbrados a Java usan nombres excesivamente largos, los que usan C usan excesivamente cortos. ¡En algún lugar en el medio es bueno!

Piensa en escribir tu código para que los humanos puedan leerlo, esto te ayudará a hacer que tus líneas sean más cortas. Las líneas largas no son tan legibles: el ojo puede perder el rastro al escanear a través de la línea.

Para las cosas que absolutamente deben ser largas, piense en una forma consistente de romper la línea y envolverla que cumpla con el límite de longitud de la línea y que sea legible.

Hay algunas cosas que puede hacer para ayudar:

• Lo más importante: abstraiga fragmentos de código profundamente anidados en subrutinas / métodos / procedimientos / funciones bien nombrados o como los llame su lenguaje. También resuma fragmentos de código detallados. Esto no solo hace que sea más fácil mantener 80 columnas, sino que también ayuda a mantener sus subrutinas razonablemente cortas. Encuentro algo más de 60 líneas demasiado largo, y 30 o 40 es mejor.
• Mantenga las hendiduras en 4 columnas por nivel de anidamiento
• Rompe largas líneas cerca de la izquierda.
• Abreviar. En lugar de nombres como GrandTotalOfAllNonNegativeElements, puede usar un nombre como NonNegTotal. Simplemente trate de ser coherente con sus abreviaturas y, si cree que pueden ser ambiguas, agregue documentación cerca de la parte superior del archivo que indique lo que significan las abreviaturas.
• Sangría con espacios en lugar de pestañas. Aquí no estoy hablando de qué tecla presionaste en tu editor para que se sangrara, estoy hablando de los caracteres en tu código fuente. Algunos editores piensan que un carácter de tabulación indica sangría al siguiente múltiplo de 4 columnas, pero el estándar histórico es 8. Entonces, si su archivo fuente comienza cada línea con caracteres de tabulación, su editor le muestra como 4 columnas y se imprime o muestra usando un software que piensa que una pestaña es el 8 estándar, las líneas que parecen estar bien por debajo de 80 columnas pueden aparecer también por encima de 80. Además, si una de sus líneas comienza con, digamos, 1 carácter de tabulación, y la siguiente comienza con 4 espacios, aparecerán alineados, pero cuando los muestre un software que piense que una pestaña tiene 8 columnas, no se alinearán en absoluto. Configure su editor para convertir pestañas en espacios cuando guarde archivos.

80 es algo arbitrario en estos días, pero sigue siendo una buena idea. El ancho estándar para los terminales mapeados de caracteres de estilo antiguo (como el VT100) era de 80 columnas, y ese ancho estándar para el código se ha mantenido a pesar de la facilidad con la que ahora podemos tener 150 o 200 ventanas de editor de columnas. La cuestión es que cuanto más ancha es una línea de texto, más difícil es para sus ojos seguir correctamente a través de la línea. Solo intenta hacer una ventana realmente amplia de líneas de texto realmente largas y léelo. Es mucho más difícil de leer que una ventana de 80 columnas. Por supuesto, si hace demasiado estrecho, entonces no obtiene mucho en una página y pasa todo su tiempo desplazándose. 80 columnas parece ser un buen compromiso.

La otra razón para apegarse a 80 columnas, y aún más importante, para mantener los procedimientos en 40-60 líneas es que lo alienta a hacer un resumen. Cada método que escriba debe ser una simple abstracción que haga una cosa fácil de entender. Mantener cada función pequeña y simple es un gran paso para hacerla comprensible. Y ese es un paso crítico para hacer que su código sea mantenible.

El cómo ha sido explicado. Pero una pregunta más relevante es: “¿Por qué deberían hacerlo?” Y ha señalado, ya no hay ninguna razón técnica para adherirse a tal restricción. Sin embargo, existe el argumento de legibilidad.

Mi enfoque personal: trato de mantener el código real en 80 columnas y solo uso sangría de 2 caracteres para mantener las cosas compactas. Sin embargo, uso muchos comentarios, la mayoría de los cuales están en línea a la derecha del código, como una segunda columna para explicar, en un nivel superior, lo que sucede en el código cuando puede no ser obvio. (He desarrollado mis propias macros Emacs para facilitar el mantenimiento de una segunda columna ordenada). Permito que mis comentarios se extiendan más allá de 80 columnas, por ejemplo, a 118 columnas. Incluso si algún sistema perverso trunca mis archivos de programa en 80 columnas, el código seguirá funcionando. Solo se pierden algunos comentarios.

En términos generales, se realiza mediante la reducción de la complejidad de las declaraciones y no utilizando nombres de variables demasiado largos.

Prácticamente, es un legado que se remonta a los programas en FORTRAN y COBOL que se escriben en tarjetas perforadas de 80 columnas, y los primeros TTY de vidrio (terminales de computadora con pantallas CRT y teclados, en lugar de TeleTYpewriters ) son 80 columnas por 24 líneas.

La primera PC tenía 80 columnas por 25 líneas, por lo que podía usar la línea 25 como línea de estado, ya que la mayoría de los terminales, incluido el IBM 3101, tenían 24 líneas más una línea de estado, y esto era necesario para que las PC de IBM emularan a IBM terminales.

Al codificar en tarjetas perforadas (tarjetas Hollerith), las columnas 73-80 se reservaron para un número de secuencia; de esa manera, si dejaste caer una baraja de cartas, podrías colocar las cartas en un clasificador de cartas, y las volvería a poner en el orden correcto. Dependiendo del idioma, las primeras 6 u 8 columnas estaban reservadas, con la primera columna generalmente reservada para un carácter de continuación (“C” en FORTRAN), por lo que eran posibles declaraciones largas … simplemente no líneas largas, y el resto reservado para etiquetas para cosas como objetivos GOTO.

Técnicamente, hay muchas razones por las que resulta una buena idea mantener las líneas cortas, la principal es la psicología cognitiva.

En 1956, George A. Miller escribió un artículo de gran prestigio titulado ” El número mágico siete, más o menos dos: algunos límites en nuestra capacidad para procesar información “. Este artículo es uno de los artículos de psicología más citados jamás escritos.

En él, argumenta que el número de objetos que un humano promedio puede contener en la memoria de trabajo (memoria a corto plazo) es siete, más o menos dos.

Este documento es la razón por la cual los números de teléfono tenían siete dígitos: para mover algo de la memoria a corto plazo a la memoria a largo plazo, tiene que caber en su memoria de trabajo.

El reciente movimiento de “debe agregar un código de área a todo” por parte de la compañía telefónica se debe a la proliferación de VNO ( operadores de red virtual ) y al hecho de que, hasta hace poco, el cambio de equipo requería que los números de teléfono se asignaran en bloques de 10,000 , por lo que la única forma de darles bloques de números era aumentar el número de códigos de área en uso.

Si está interesado, puede leer la totalidad del documento aquí: The Magical Number Seven, Plus o Minus Two.

Dado un tamaño de nombre de variable promedio de 8 caracteres, menos las columnas vacías iniciales, con un espacio entre variables y operadores, que proporciona entre 6 y 8 elementos para mantener en la memoria de trabajo para una declaración de línea de 80 columnas en un lenguaje de computadora como “C “o” Python “.

Por lo tanto, resulta “justo para que alguien que lea el código más tarde pueda entenderlo”.

En términos generales, si uno quiere escribir código legible, intentan mantener el código por debajo del límite de 80 columnas, si pueden, y si no pueden, al menos intentan hacerlo subcláusulas independientes separadas por operadores, con línea descansos, tales como:

if ((primera declaración condicional) &
((segunda declaración condicional) |
(tercera declaración condicional))) {
…
}

El punto es que puede mantener tres cosas en la memoria de trabajo mucho más fácil de lo que puede mantener cada uno de los elementos de todas las declaraciones en la memoria de trabajo.

Prácticamente, si es posible, desea evitar este tipo de codificación, y solo debe ajustarse a la declaración debajo del límite de 80 columnas para no gravar a la persona que viene después de que usted intenta mantener el código.

Puede usar líneas más largas, pero si lo hace, incluso si está manteniendo el código, si vuelve a visitarlo en dos años, probablemente se preguntará qué hace el código durante mucho más tiempo del que le llevaría comprender una línea más corta. .

Ya hay muchas respuestas excelentes, especialmente la de Peter Schachte, por lo que lo más probable es que haga eco de mucho de lo que ya se ha dicho.

En primer lugar, 80 caracteres generalmente me parecen un límite demasiado estrecho. Mi umbral personal, establecido empíricamente, parece estar en algún lugar en el rango de 100-120. No lo sigo conscientemente, pero existe una sensación definitiva de “esto se está haciendo demasiado largo” cuando la longitud de la línea se acerca a ese rango.

También estoy de acuerdo en que la longitud de la línea no es la única longitud que es importante para la comprensión. Un método debe caber en una pantalla, su estructura es evidente de un vistazo. Por ejemplo, no ponga llaves de apertura en una nueva línea. No proporcionan más separación visual que simplemente sangrar el código correctamente y desperdician espacio en la pantalla.

Volviendo al tema principal, el principal medio para evitar líneas demasiado largas es liberal, a veces refactorización moderadamente obsesiva. Condiciones complejas en if declaraciones se separan en piezas funcionales más pequeñas, tal vez en sus propias líneas separadas, tal vez incluso en sus propios métodos privados. Dividir largas cadenas de llamadas a métodos. No use más de dos o tres palabras para los identificadores. No use marcos mal diseñados. No diseñe mal los frameworks (es decir, no use patrones por el simple hecho de haber usado patrones). Si su lenguaje de programación de elección permite construcciones funcionales, observe si puede usarlas para abstraer la estructura común de sus algoritmos, y luego mezcle y combine apropiadamente.

Por otro lado, no lo lleves a los extremos. Siempre use espacios en blanco alrededor de los operadores, no use trucos arcanos que oculten la intención del código. El objetivo no es un cierto número de caracteres, el objetivo es una fácil lectura, que es un delicado equilibrio entre conciso y comprensible. Esta es la vida real, después de todo, no es un torneo de Code Golf.

Saltos de línea frecuentes.

Cambié a 112 caracteres (se adapta bien a GitHub) y uso el formato clang para C ++ (su configuración es efectivamente “BasedOnStyle: Google, ColumnLimit: 112).

¿Por qué usamos letras mayúsculas y minúsculas en lenguaje escrito?

Porque ayuda a la legibilidad, es decir, reduce la energía que un lector debe usar para comprender el texto.

Tuve la oportunidad de usar tarjetas perforadas para programar hace muchos años y en ese momento no había letras minúsculas disponibles: aún ahora, si echas un vistazo a un programa Fortran, es probable que aún encuentres código en mayúsculas. Ilegible desde mi punto de vista.

Algo similar se aplica a las líneas largas: su ojo está obligado a seguir una línea larga con el riesgo de cambiar a la línea adyacente (superior o inferior), así que trato de mantener las líneas de mi código cortas: 80 caracteres es una elección razonable.

Por cierto, cada vez es más difícil ya que la refactorización automática empuja a los programadores a usar nombres de variables siempre más largos y más significativos y esto obliga a las líneas a alargarse más y más.

¿Tan frecuentemente corto la declaración a la mitad, por ejemplo cuando uso? : en lenguajes derivados de C o situaciones similares y estoy convencido de que esto ayuda a la legibilidad de mi código.

Normalmente escribo código con nombres cortos de variables y luego, un par de días después de hacer una auto revisión de mi propio código, agrego comentarios significativos y cambio los nombres cortos de variables con nombres más largos y más significativos: esto es cuando reformateo mis líneas que se vuelven mucho más largas debido a este postprocesamiento.

Aquí hay muchos buenos consejos sobre cómo estructurar bien su código, así que voy a tomar un rumbo ligeramente diferente.

Si está formateando su propio código, lo está haciendo mal. La mayoría de los idiomas principales tienen herramientas de formateo automático. Para los idiomas más nuevos, hay un formateador oficial con un estándar oficial (rustfmt y gofmt se destacan en este sentido). Personalmente, creo que Clang-tidy es una de las mejores herramientas que tenemos. Una vez que te acostumbras a usar una de esas herramientas, la parte de formateo de código de tu cerebro simplemente se apaga, y eso libera espacio para tareas que valen la pena.

En lugar de dar una respuesta muy larga, solo tengo 3 consejos.

1. Usando su editor de código, habilite la configuración que muestra una línea vertical de 80 caracteres de ancho. Si su editor no tiene esa función, habilite el ajuste de texto con 80 caracteres.
2. Si alguna vez supera los 80 caracteres en una línea determinada. Haga lo que pueda para acortarlo mientras conserva o mejora la legibilidad y la consistencia.
3. Asegúrese de que su código aún se ejecute como espera que sea.

En cuanto a las estrategias detalladas, aquí hay algunas de la parte superior de mi cabeza. Úselos sabiamente caso por caso:

1. Reduce la sangría
2. Considere el uso de return, break, continue sobre construcciones anidadas.
3. Considerar la creación de métodos auxiliares.
4. Considere las técnicas de programación funcional permitidas por su lenguaje.
5. Sepa dónde es posible dividir una cadena larga o una cadena de invocaciones de métodos en varias líneas.
6. Considere identificadores más cortos pero aún legibles.
7. Considere la creación de variables para “almacenar” los resultados de condiciones largas.
8. Considere la creación de un alias más corto si su idioma lo permite (importe x como y)

Eso no es realmente cierto, ya no vivimos en los 80, ahora tenemos pantallas más grandes que pueden contener más personajes, sin embargo, si necesita mantener una línea corta para mejorar la visibilidad, hay dos técnicas y media.

1. Divide la línea en más líneas (generalmente después del punto pero depende del idioma)
2. Cree funciones pequeñas o incluso clases con un nombre descriptivo y significativo y utilícelas en esa gran línea.
3. Intenta no tener código anidado. En realidad, esto es algo muy común y desafortunado incluso para los mejores programadores. Personalmente, odio el código anidado porque se vuelve realmente difícil seguir los corchetes si es mucho código. Entonces, en lugar de escribir una condición y luego incluir una gran cantidad de código dentro de la instrucción if, intente revertir la condición, escriba solo el fragmento más pequeño de código y mantenga una estructura plana como sea posible.

Si tiene una condición importante, puede dividirla en fragmentos más pequeños legibles y asignar el resultado a una variable significativa y descriptiva como esta:

var isAdult = edad> 18;

var isAuthenticatedMember = user.isAuthenticated;

If (isAdult && isAuthenticatedMember) {

// hacer algo

}

Hoy en día es bastante difícil mantener el estándar de línea de 80 caracteres. Estamos mimados por IDE y la función de autocompletar, y nos enfocamos en la facilidad de mantenimiento y legibilidad de nuestro código hasta el punto de que cada variable y método es demasiado largo para que una sola declaración se ajuste al bloque de 80 caracteres.

Lo que hacemos es comenzar una nueva línea en el punto apropiado. Realmente depende del lenguaje en uso, pero la mayoría del lenguaje de programación nos permite comenzar una nueva línea sin especificar nada. Por ejemplo, en C #:

actionContext.ControllerContext.RouteData.Values.TryGetValue("userId", out userIdFromRoute);

podría reescribirse como

actionContext.ControllerContext.RouteData.Values
. TryGetValue (“userId”, fuera userIdFromRoute);

El compilador es lo suficientemente inteligente como para saber que son iguales.

El programador puede evitar líneas de más de 80 caracteres de la siguiente manera:

1. Haciendo una operación por línea.
2. Usar nombres de variables de una o dos palabras.

Hacer una sola operación por línea hace que el código sea lineal y más fácil de leer para la mayoría de los programadores. El siguiente grupo de programadores que leerán su código son su audiencia; no el compilador / intérprete. Si ahora hay una gran cantidad de líneas, puede colocarlas en una función bien nombrada. Incluso un libro de recetas tendrá una receta separada para salsas comunes y no repetirá esos pasos en cada receta que las use.

Con espacios de nombre, programación orientada a objetos o simplemente una buena arquitectura, puede dividir sistemas grandes en fragmentos de tamaño mediano que permitan el contexto al leer el código. Los nombres de las variables pueden ser más cortos cuando hay un contexto bien comunicado para el código. Los nombres largos de variables son un síntoma de que no se ha pensado en la arquitectura de los sistemas de software.

No te molestes en intentar hacer esto. Solo trate de mantener sus declaraciones breves y legibles. No tenga miedo de usar variables locales descartables si le ayuda a hacer esto.

Vea mi respuesta más detallada a una pregunta similar: la respuesta de Ryan Cook a ¿Cuál es el número preferido de caracteres por línea para los programadores?

Nosotros no

El estándar de 80 columnas desapareció con los viejos terminales de 80 columnas, alrededor de 1990. En estos días con monitores más grandes, nunca he oído hablar de nadie que use un estándar de menos de 120 columnas, y muchas personas usan pantallas mucho más anchas que eso.

Pero estoy de acuerdo con el resto de lo que escribió Peter Schachte. Es mejor mantener las líneas cortas y las funciones cortas también. Más fácil de leer. Por ejemplo, si tiene 10 pruebas diferentes dentro de una instrucción if condicional, no tiene que hacerlo todo en una línea. Puede anidar una segunda declaración if dentro de la primera. También puede realizar llamadas a funciones si su sangría es demasiado profunda. No es difícil de hacer en absoluto.