¿Hay alguna razón válida para imponer un ancho máximo de 80 caracteres en un archivo de código, hoy en día? [cerrado]

Seriamente. En un monitor de 22 ", solo cubre quizás una cuarta parte de la pantalla. Necesito algo de munición para eliminar esta regla.

No estoy diciendo que no debería haber un límite; Solo digo que 80 caracteres es muy pequeño.

Creo que la práctica de mantener el código en 80 (o 79) columnas se creó originalmente para admitir que las personas editen código en terminales tontas de 80 columnas o en impresiones de 80 columnas. Esos requisitos han desaparecido en su mayoría ahora, pero todavía hay razones válidas para mantener la regla de las 80 columnas:

• Para evitar ajustes al copiar código en correos electrónicos, páginas web y libros.
• Para ver varias ventanas de origen lado a lado o usando un visor de diferencias lado a lado.
• Para mejorar la legibilidad. El código estrecho se puede leer rápidamente sin tener que escanear los ojos de lado a lado.

Creo que el último punto es el más importante. Aunque las pantallas han crecido en tamaño y resolución en los últimos años, los ojos no .

El origen del formato de texto de 80 columnas es anterior a los terminales de 80 columnas: ¡la tarjeta perforada de IBM se remonta a 1928 ! Esto es una reminiscencia de la historia (apócrifa) de que el ancho del ferrocarril de los EE. UU. Estaba determinado por el ancho de las ruedas del carro en la Gran Bretaña romana.

A veces me parece un poco restrictivo, pero tiene sentido tener un límite estándar, por lo que 80 columnas es.

Aquí está el mismo tema cubierto por Slashdot .

Y aquí hay una declaración de Fortran de la vieja escuela:

80 caracteres es un límite ridículo en estos días. Divida sus líneas de código donde tenga sentido, no de acuerdo con ningún límite de caracteres arbitrario.

Debe hacerlo por el bien de todos los que no tienen un monitor de pantalla ancha de 22 pulgadas. Personalmente, trabajo en un monitor de 17 pulgadas 4: 3, y lo encuentro más que suficientemente ancho. Sin embargo, también tengo 3 de esos monitores, así que todavía tengo mucho espacio de pantalla utilizable.

No solo eso, sino que el ojo humano realmente tiene problemas para leer el texto si las líneas son demasiado largas. Es muy fácil perderse en qué línea se encuentra. Los periódicos miden 17 pulgadas de ancho (o algo así), pero no los ves escribiendo en toda la página, lo mismo ocurre con las revistas y otros artículos impresos. En realidad, es más fácil de leer si mantiene las columnas estrechas.

Cuando tiene una secuencia de declaraciones que se repiten con pequeñas variaciones, puede ser más fácil ver las similitudes y diferencias si se agrupan en líneas para que las diferencias se alineen verticalmente.

Yo diría que lo siguiente es mucho más legible de lo que hubiera sido si lo hubiera dividido en varias líneas:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

Actualización: en los comentarios se ha sugerido que esta sería una forma más sucinta de hacer lo anterior:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

aunque ahora cabe en 80 columnas, creo que mi punto sigue en pie y acabo de elegir un mal ejemplo. Todavía demuestra que colocar varias declaraciones en una línea puede mejorar la legibilidad.

La impresión de una fuente monoespaciada en tamaños predeterminados es (en papel A4) 80 columnas por 66 líneas.

Aprovecho la ventaja de las pantallas más grandes para tener múltiples piezas de código una al lado de la otra.

No obtendrás ninguna munición mía. De hecho, odiaría verlo cambiar ya que en emergencias todavía veo casos raros en los que necesito cambiar el código desde una consola de texto.

Las líneas súper largas son más difíciles de leer. El hecho de que pueda tener 300 caracteres en su monitor no significa que deba hacer las líneas tan largas. 300 caracteres también es demasiado complejo para una declaración a menos que no tenga otra opción (una llamada que necesita una gran cantidad de parámetros).

Utilizo 80 caracteres como regla general, pero iré más allá si cumplirlo significaría poner un salto de línea en una ubicación no deseada.

Lo único que hago cumplir para permanecer dentro de 80 caracteres es mi comentario.

Personalmente ... estoy dedicando todo mi poder mental (lo poco que hay) a la codificación correcta, es un dolor tener que regresar y dividir todo en el límite de 80 caracteres cuando podría pasar mi tiempo en la próxima función . Sí, supongo que Resharper podría hacerlo por mí, pero luego me asusta un poco que un producto de terceros tome decisiones sobre el diseño de mi código y lo cambie ("Por favor, no divida mi código en dos líneas HAL. HAL?" )

Dicho esto, trabajo en un equipo bastante pequeño y todos nuestros monitores son bastante grandes, por lo que preocuparse por lo que molesta a mis compañeros programadores no es una gran preocupación en lo que respecta a eso.

Parece que algunos idiomas fomentan líneas de código más largas en aras de una mayor rentabilidad (abreviatura si las declaraciones).

Tengo dos monitores de 20 "1600x1200 y me quedo con 80 columnas porque me permite mostrar varias ventanas del editor de texto una al lado de la otra. Usando la fuente '6x13' (la fuente tradicional xterm) 80 columnas ocupan 480 píxeles más la barra de desplazamiento y los bordes de las ventanas. Esto permite tener tres ventanas de este tipo en un monitor de 1600x1200. En Windows, la fuente de la consola Lucida no es suficiente (el tamaño mínimo utilizable es de 7 píxeles de ancho), pero un monitor de 1280x1024 mostrará dos columnas y un monitor de 1920x1200, como un HP LP2465 , mostrará 3. También dejará un poco de espacio al lado para los distintos exploradores, propiedades y otras ventanas de Visual Studio.

Además, las líneas de texto muy largas son difíciles de leer. Para texto el óptimo es de 66 caracteres. Hay un punto en el que los identificadores excesivamente largos comienzan a ser contraproducentes porque dificultan el diseño coherente del código. Un buen diseño y sangría proporciona pistas visuales sobre la estructura del código y algunos lenguajes (Python me viene a la mente) usan la sangría explícitamente para esto.

Sin embargo, las bibliotecas de clases estándar para Java y .Net tienden a tener una preponderancia de identificadores muy largos, por lo que no necesariamente se puede garantizar que se pueda hacer esto. En este caso, el diseño de código con saltos de línea todavía ayuda a hacer explícita la estructura.

Tenga en cuenta que puede obtener versiones de Windows de las fuentes '6x13' aquí .

La gente dice que las largas líneas de código tienden a ser complejas. Considere una clase de Java simple:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Tiene 94 caracteres de longitud y el nombre de la clase es bastante corto (según los estándares GWT). Sería difícil de leer en 2 líneas y es muy legible en una línea. Siendo pragmático al respecto y permitiendo así la "compatibilidad con versiones anteriores", diría que 100 caracteres es el ancho correcto.

Las otras respuestas ya resumieron las cosas muy bien, pero también vale la pena considerar cuándo es posible que desee copiar y pegar algún código en un correo electrónico, o si no es un código, entonces un diff.

Ese es un momento en el que es útil tener un "ancho máximo".

No eres la única persona que va a mantener tu código.

La siguiente persona que lo haga podría tener una pantalla de 17 "o necesitar fuentes grandes para leer el texto. El límite tiene que estar en algún lugar y 80 caracteres es la convención debido a las limitaciones de la pantalla anterior. ¿Puede pensar en algún nuevo estándar (120) y ¿Por qué es una buena idea usar eso aparte de "eso es lo que cabe en mi monitor en la fuente Xpt?"

Recuerde, siempre hay excepciones para cada regla, por lo que tiene una línea o bloque de código en particular que tiene sentido ser más de 80 caracteres y luego ser rebelde.

Pero primero tómese el tiempo para pensar "¿es este código realmente tan malo que no puede vivir dentro de 80 caracteres?"

En el estándar de codificación de Linux, no solo mantienen el límite de 80 caracteres, sino que también usan una sangría de 8 espacios.

Parte del razonamiento es que si alguna vez alcanza el margen correcto, debería considerar mover un nivel de sangría a una función separada.

Esto hará que el código sea más claro porque, independientemente de las longitudes de sangría, es más difícil leer el código con muchas estructuras de control anidadas.

He ampliado mi código a 100 caracteres, lo que cabe cómodamente en menos de la mitad de mi pantalla en mi Macbook. 120 caracteres es probablemente el límite antes de que las líneas comiencen a ser demasiado largas y complejas. No desea ampliar demasiado, de lo contrario, fomenta declaraciones compuestas y estructuras de control profundamente anidadas.

El margen derecho es la forma natural de decirle que realice una refactorización de método adicional .

Me pregunto si esto podría causar más problemas hoy en día. Recuerde que en C (y posiblemente en otros lenguajes) hay reglas sobre la duración de un nombre de función. Por lo tanto, a menudo ve nombres muy difíciles de entender en el código C. Lo bueno es que no usan mucho espacio. Pero cada vez que miro el código en algún lenguaje como C # o Java, los nombres de los métodos son a menudo muy largos, lo que hace que sea casi imposible mantener su código con una longitud de 80 caracteres. No creo que 80 caracteres sean válidos hoy, a menos que necesites poder imprimir el código, etc.

Como autor de las pautas de codificación para mi empleador, he aumentado la longitud de la línea de 80 a 132. ¿Por qué este valor? Bueno, como otros señalaron, 80 es la longitud de muchos terminales de hardware antiguos. ¡Y 132 también lo es! Es el ancho de línea cuando los terminales están en modo ancho . Cualquier impresora también podría hacer copias impresas en modo ancho con una fuente condensada.

La razón para no quedarme en 80 es que prefiero

• prefiera nombres más largos con un significado para identificadores
• no te molestes con typedefs para estructuras y enumeraciones en C (¡son MALOS, OCULTAN información útil! Pregunta a Peter van der Linden en "Deep C Secrets" si no lo crees), entonces el código tiene más struct FOO func(struct BAR *aWhatever, ...)que código de fanáticos de typedef .

y bajo estas reglas, solo 80 caracteres / línea causan que las líneas feas se envuelvan con más frecuencia de lo que mis ojos consideran aceptable (principalmente en prototipos y definiciones de funciones).

Como han dicho otros, creo que es mejor para (1) imprimir y (2) mostrar varios archivos uno al lado del otro verticalmente.

Me gusta limitar mi ancho a 100 caracteres más o menos para permitir dos editores SxS en un monitor de pantalla panorámica. No creo que haya ninguna buena razón para un límite de exactamente 80 caracteres más.

Usa fuentes proporcionales.

Lo digo en serio. Por lo general, puedo obtener la equivalencia de 100-120 caracteres en una línea sin sacrificar la legibilidad o la capacidad de impresión. De hecho, es aún más fácil de leer con una buena fuente (p. Ej., Verdana) y un color de sintaxis. Parece un poco extraño por unos días, pero rápidamente te acostumbras.

Intento mantener las cosas cerca de 80 caracteres por una simple razón: mucho más que eso significa que mi código se está volviendo demasiado complicado. Los nombres de propiedad / método excesivamente detallados, los nombres de clase, etc. causan tanto daño como los concisos.

Soy principalmente un codificador de Python, por lo que esto produce dos conjuntos de limitaciones:

1. No escriba largas líneas de código.
2. No sangres demasiado

Cuando comienzas a alcanzar dos o tres niveles de sangría, tu lógica se vuelve confusa. Si no puede mantener un solo bloque en la misma página, su código se está volviendo demasiado complicado y difícil de recordar. Si no puede mantener una sola línea dentro de 80 caracteres, su línea se está volviendo demasiado complicada.

En Python es fácil escribir código relativamente conciso (ver codegolf) a expensas de la legibilidad, pero es aún más fácil escribir código detallado a expensas de la legibilidad. Los métodos auxiliares no son malos, ni las clases auxiliares. La abstracción excesiva puede ser un problema, pero ese es otro desafío de la programación.

En caso de duda en un lenguaje como C, escriba las funciones auxiliares e instálelas si no desea la sobrecarga de llamar a otra función y saltar hacia atrás. En la mayoría de los casos, el compilador manejará las cosas de manera inteligente para usted.

Ya hay muchas buenas respuestas para esto, pero vale la pena mencionar que en su IDE puede tener una lista de archivos a la izquierda y una lista de funciones a la derecha (o cualquier otra configuración).

Tu código es solo una parte del entorno.

Creo que no imponer 80 caracteres significa eventualmente ajustar las palabras.
En mi opinión, cualquier longitud elegida para una línea de ancho máximo no siempre es apropiada y el ajuste de palabras debe ser una posible respuesta.
Y eso no es tan fácil como parece.

Está implementado en jedit _{(fuente: jedit.org )} que ofrece _{ajuste de} texto

¡Pero se echa mucho de menos en el eclipse desde hace mucho tiempo ! (desde 2003, de hecho), principalmente porque un ajuste de texto para el editor de texto implica:

• La información de línea envuelta es para el visor de texto, navegación de código, reglas verticales.
• Se requiere información de línea sin envolver para funcionalidades como ir a línea, columna de regla de numeración de línea, resaltado de línea actual, guardar archivo.

De hecho, sigo una regla similar para mi propio código, pero solo por imprimir el código en una página A4: 80 columnas tienen aproximadamente el ancho correcto para el tamaño de fuente deseado.

Pero esa es una preferencia personal y probablemente no lo que buscabas (ya que quieres que la munición vaya para otro lado).

¿Qué no cuestiona el razonamiento detrás del límite? En serio, si nadie puede encontrar una buena razón por la cual es así, tiene un buen caso para que se elimine de sus estándares de codificación.

Estoy diferenciado lado a lado todo el día y no tengo un monitor de 22 pulgadas. No sé si alguna vez lo haré. Esto, por supuesto, es de poco interés para los programadores de solo escritura que disfrutan de la codificación de flechas y las líneas de 300 caracteres.

Sí, porque incluso hoy en día, algunos de nosotros estamos codificando en terminales (ok, en su mayoría emuladores de terminal), donde la pantalla solo puede mostrar 80 caracteres. Entonces, al menos para la codificación que hago, realmente aprecio la regla de 80 caracteres.

Sigo pensando que el límite no está limitado en la parte visual. Claro, los monitores y las resoluciones son lo suficientemente grandes como para mostrar aún más caracteres en una línea hoy en día, pero ¿aumenta la legibilidad?

Si el límite se aplica realmente, también es una buena razón para repensar el código y no poner todo en una línea. Es lo mismo con la sangría: si necesita muchos niveles, su código debe ser repensado.

Romper con 80 caracteres es algo que haces mientras codificas, no después. Lo mismo con los comentarios, por supuesto. La mayoría de los editores pueden ayudarlo a ver dónde está el límite de 80 caracteres.

(Esto puede ser un poco OT, pero en Eclipse hay una opción que formatea el código cuando lo guarda (de acuerdo con las reglas que desee). Esto es un poco extraño al principio, pero después de un tiempo comienza a aceptar que el el formato no está más en sus manos que el código generado).

Si tuviéramos uno de estos , ¡no estaríamos teniendo esta discusión! ;-)

Pero en serio, los problemas que las personas han planteado en sus respuestas son bastante legítimos. Sin embargo, el póster original no argumentaba en contra de un límite, simplemente que 80 columnas son muy pocas.

El problema de enviar fragmentos de código por correo electrónico tiene algún mérito. Pero teniendo en cuenta las cosas malas que la mayoría de los clientes de correo electrónico hacen al texto preformateado, creo que el ajuste de línea es solo uno de sus problemas.

En cuanto a la impresión Por lo general encontramos que 100 líneas de caracteres serán muy caber cómodamente en una página impresa.

Intento mantener mis líneas debajo de 80 columnas. La razón más fuerte es que a menudo me encuentro usando grepy buscando lessmi código cuando trabajo en la línea de comandos. Realmente no me gusta cómo los terminales rompen las largas líneas de origen (después de todo, no están hechas para ese trabajo). Otra razón es que creo que se ve mejor si todo encaja en la línea y el editor no lo rompe. Por ejemplo, tener parámetros de llamadas de función largas bien alineados uno debajo del otro y cosas similares.