¿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]

159

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.

TraumaPony
fuente
Todas las respuestas indican más o menos lo que quería agregar. Para darle un ejemplo de la vida real: tengo un x61s, la resolución es 1024x768. Cuando estoy de viaje, no tengo mi monitor elegante. Abrir el código en mi IDE es una molestia cuando excede esta regla.
Hasta el
Incluso si tiene un conjunto de 3 monitores. Esta no es una razón para sacudir la cabeza de derecha a izquierda y hacia atrás. Siempre. Ah-ha-ha. En realidad, el ojo se mueve más rápido que la cabeza. ¿Conoces las columnas en los periódicos? La razón del ancho es la conveniencia del ojo / cabeza / hombre.
Ivan Black

Respuestas:

257

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 .

Will Harris
fuente
77
Puede que hayan "desaparecido en gran medida", pero no del todo. Tiendo a trabajar con dos configuraciones diferentes: 1) en una ventana ssh conectada a una máquina remota. que tiene 80 caracteres de ancho por defecto. y 2) En Visual Studio, con dos paneles uno al lado del otro para que pueda ver el encabezado y el archivo cpp al mismo tiempo.
Enno
10
@steffenj: En realidad, los libros tienden a disparar durante unos 66 caracteres por línea (aunque esto varía un poco dependiendo de otros parámetros) porque las líneas más largas hacen la lectura hacen más difícil. Se podría argumentar la longitud máxima de la línea de código , pero 80 es conveniente por razones históricas y prácticas.
Steve S
68
El problema es que al obligar a las personas a mantener cortas las líneas, tienden a usar nombres menos significativos ...
Ian Ringrose el
44
Las observaciones sobre la legibilidad me parecen bastante interesantes, porque lo que realmente odio de los artículos de programación impresos / libros / ... es que las líneas cortas que se usan para los ejemplos de código son extremadamente difíciles de leer. Puede tener mucho sentido mover algo a una nueva línea, pero la agrupación debe ocurrir lógicamente, diseccionando la expresión de forma recursiva, no porque el dispositivo de salida accidentalmente haya alcanzado su límite. IOW, encuentro que los dispositivos que imponen restricciones tan estrechas no son adecuados para mostrar código.
Chris Lercher
44
Creo que el problema con los ejecutores de 80 columnas es que se olvidan de que el código crece en la dirección vertical. Obtiene el mismo problema, pero en la dirección vertical Y de la parte superior de este código moderno se ve horrible cuando tiene que romper declaraciones individuales en dos o, a veces, hasta cuatro o cinco líneas. NO es más legible. Con el código moderno me refiero a nombres de variables descriptivas y herencia calificativa, espacios de nombres, clases, etc. Detenga las 80 columnas no obesas, use el sentido común en su lugar. 120 es mejor, pero tampoco debería ser una regla.
Larswad
79

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:

Tarjeta perforada FORTRAN

John Carter
fuente
60

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.

Craig Day
fuente
El límite de caracteres no te dice DÓNDE tienes que dividir una línea de código, pero CUANDO
gztomas
No, no es. Si escribe una línea de más de 80 caracteres, probablemente ya tenga un problema en la complejidad de la expresión o la estrategia de denominación. Como otros han mencionado, la legibilidad es una preocupación principal y la velocidad de lectura comienza a caer por encima de 60-66 caracteres (tipografía, basada en la fisiología humana).
sola
@sola Tu comentario aparece aquí con 98 caracteres, y es un lenguaje natural denso no nativo (para mí) de entender. Completamente legible. Un código con hasta 3-4 sangrías, marcadores de sintaxis, etc. es aún más fácil.
Viyps
Accidentalmente rechacé esta respuesta y ya no puedo votarla. :(
Andy
35

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.

Kibbee
fuente
14
No cuando agregas sangría en la mezcla. Si usa 4 espacios por sangría, y está en algo así como espacio de nombres-> clase-> método-> if-> for, eso es 1/5 de su espacio volado.
TraumaPony
Siempre puede establecer la regla en 80 caracteres desde la sangría. De esa manera el ojo puede seguirlo fácilmente.
Vincent McNabb
A veces, (pero no siempre) desearía que .Net tuviera un espacio de nombres automático para que no tuviera que definir el espacio de nombres en el archivo. Eso ensucia seriamente la alineación de su código. si desea espacios de nombres anidados, tiene problemas realmente grandes.
Kibbee
13
Sin embargo, leer la prosa no es lo mismo que leer el código.
Atario
3
+1 para periódicos, gran ejemplo. @Atario, leer BUEN código es muy parecido a leer en prosa.
Todd Chaffee
23

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.

Sam Hasler
fuente
8
Al decir que solo hay pequeñas diferencias de línea a línea, también dice que hay una gran cantidad de código redundante. Eliminar algo de eso podría disminuir significativamente el número de columnas y aún estar alineado verticalmente.
miedo el
@mxp: de acuerdo. Si hay una manera más concisa de escribir lo anterior, me interesaría verlo.
Sam Hasler
Estoy de acuerdo con la idea general, pero el ejemplo ... ¿Qué pasa con esto: switch (...) {case ... BL: dxDir = - 1; dyDir = - 1; descanso; caso ... BR: dxDir = + 1; dyDir = - 1; descanso; ...} ... ["X"] = pt1.x + dxDir * Rad ... X; ... ["Y"] = pt1.y + dyDir * Rad ... Y;
Yarik
38
El hecho de que necesito desplazarme horizontalmente el primero de los dos ejemplos prueba la pinta de que las líneas más cortas son mejores :-)
Enno
1
No entiendo el odio por el desplazamiento? Es una opinión común, y no digo que esté mal, simplemente no lo entiendo. Especialmente si está en un editor de código, ni siquiera necesita mover las manos del teclado para llegar al mouse, justo (ctrl+)arrowencima o presionarend
KOGI
21

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

Josh
fuente
16

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.

Twan
fuente
14

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.

Loren Pechtel
fuente
Hay estudios que muestran que las personas pueden leer y seguir x cantidad de caracteres / palabras, antes de perder el rastro. Estoy pensando que 80 está allí en alguna parte. Sin embargo, no tengo ninguna fuente para respaldar eso.
Hasta el
Sí, creo que realmente, no se trata de mantener las líneas cortas sino de mantenerlas limpias / concisas / legibles / comprensibles.
KOGI
Si tiene un (una llamada que necesita un montón de parámetros), necesita refactorizar de todos modos.
Zarremgregarrok
@ Zarremgregarrok He visto algunas listas de parámetros muy largas en las API de Microsoft.
Loren Pechtel
@LorenPechtel ¿Eso lo hace bien escrito?
Zarremgregarrok
8

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

domusvita
fuente
7

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í .

TunbridgeWells
fuente
¡Gracias por decir esto! Los monitores grandes son una razón más para el límite de 80 líneas, por lo que puede colocar más ventanas una al lado de la otra. Sin mencionar que a veces es bueno poder imprimir el código fuente (en papel). O pegue fragmentos en otros documentos.
Dreeves
7

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.

Matyas
fuente
55
No soy fanático de las barras de desplazamiento horizontales
bryc
9
Me sorprende que nadie haya dicho esto, dado que llegué varios años tarde a esta discusión, pero creo que las nuevas líneas (tal vez con una sangría para mayor claridad) justo antes de "extender" y / o "implemente" las palabras clave todavía producirían muy código legible
mtraceur
2
Me encanta el hecho de que dice "es muy legible en una línea", mientras que al mismo tiempo no puedo leer todo el fragmento de código, ya que desborda el espacio horizontal en el navegador. Punto desaprobado.
oligofren
6

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".

usuario14038
fuente
6

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?"

pappes
fuente
1
Viviré con 80 caracteres cuando pueda tener 2spc tabstops. Mejor aún, en realidad use pestañas para la sangría, el requisito es cuando tabsize = 2, cabe en 80 columnas, usa 4 la mayor parte del tiempo para una mejor legibilidad. De esa manera, cuando realmente tiene que ahogarse en 80 columnas, puede hacerlo, pero a un precio.
Joshua el
5

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.

Ali
fuente
3
¿Qué tal leer código con muchas llamadas a funciones? Seguramente hay un compromiso entre estos dos enfoques ...
Zsolt Török
5

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 .

Schwern
fuente
5

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.

Jonas
fuente
5

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

Jens
fuente
4

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

Thomas Owens
fuente
4

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.

Jamie Eisenhart
fuente
4

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.

bgiles
fuente
Muy mala idea cuando quieres usar 'sangrías' y una fuente monoespaciada.
Bersaelor
2
@Bersaelor No, funciona bien cuando siempre sangras usando solo pestañas y configuras el ancho de la pestaña correctamente (el ancho 4 monoespaciado es como 7 proporcional). La sangría funciona, simplemente no puedes hacer arte ASCII, pero no creo que el arte ASCII pertenezca al código.
maaartinus
Personalmente, estoy bastante en el lado opuesto cuando programo. Encuentro el código proporcional realmente difícil de leer. A veces, incluso configuro el IDE para usar fuentes monoespaciales (sí, incluidos los menús).
Sebastian Mach
2

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.

Dan Udey
fuente
2

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.

Dean Rather
fuente
2

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 textotexto alternativo

¡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.
VonC
fuente
1

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.

paxdiablo
fuente
Estoy bastante seguro de que era de los días en que las pantallas del modo de texto tenían 80 caracteres de ancho.
TraumaPony
1

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.

Constantin
fuente
1

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.

CobolGuy
fuente
0

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.

inexistente
fuente
0

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

JesperE
fuente
0

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.

Andrew Edgecombe
fuente
0

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.

Johannes Schaub - litb
fuente