¿Sigue siendo relevante el límite de 80 caracteres en tiempos de monitores de pantalla ancha? [cerrado]

56

en un monitor de pantalla panorámica, se pueden ver fácilmente más de 80 caracteres a la vez, sin barras de desplazamiento. incluso linus torvalds ve el límite de 80 caracteres como obsoleto .

Entonces, ¿el límite de 80 caracteres sigue siendo relevante en tiempos de monitores de pantalla ancha?

lesmana
fuente
1
Hay una muy buena razón para mantener líneas cortas en, por ejemplo, Eclipse. Esto le permite imprimir sus programas en una impresora normal en una fuente legible sin ajuste de línea.
¿En que contexto? Si está preguntando en un contexto de programación específico, votaría para volver a abrir.
Nicole
El ajuste de texto de Visual Studio está roto, por lo que la mayoría de los usuarios lo tienen desactivado. En cambio, ponen saltos de línea a mano. Esto se ve terrible para cualquier persona con un ancho de pantalla diferente. visualstudio.uservoice.com/forums/121579-visual-studio/…
Coronel Panic

Respuestas:

28

Hay varias razones para seguir cumpliendo con un límite de 80 caracteres (o, un límite de 74 caracteres es aún mejor; permite que el código permanezca con menos de 80 columnas incluso cuando se agregan marcadores de diferencias y citas por correo electrónico, si revisa el código en listas de correo).

Incluso en la era de los monitores de pantalla panorámica, me gusta tener varias ventanas abiertas una al lado de la otra, que muestren diferentes partes del código. Por ejemplo, generalmente tengo un navegador web y un correo electrónico abiertos en una pantalla, y dos archivos y un terminal abiertos uno al lado del otro en un segundo monitor. Si tiene líneas que se ejecutan en más de 80 columnas, debe lidiar con el editor que ajusta las líneas (lo cual es feo y hace que el código sea más difícil de navegar), o amplíe sus ventanas para que no pueda caber tantas en la pantalla en una vez.

Incluso si normalmente no edita de esta manera, si alguna vez usa una herramienta de diferencias de lado a lado, apreciará los archivos con longitudes de línea razonables que harán que su diferencia sea más fácil de ver.

También hay un problema de densidad de código. Me gusta tener mucho contexto al leer el código. Es mucho más rápido mirar hacia arriba y hacia abajo de una ventana que desplazarse. Si tiene líneas muy largas, también tiende a tener líneas que varían mucho en longitud, lo que lleva a una gran cantidad de espacio en pantalla desperdiciado y es capaz de colocar menos código en la pantalla en un momento dado en general.

Y, por último, si tiene líneas muy largas, eso generalmente significa que tiene líneas muy complicadas, una indagación profunda o que tiene identificadores muy largos. Todo esto puede ser un problema. Las líneas complicadas probablemente están haciendo demasiado; Si puede dividirlo en varias líneas más simples, probablemente debería hacerlo. La sangría profunda significa que probablemente esté anidando demasiados bucles y condicionales, lo que puede hacer que su código fluya confuso; considerando refactorizar en varias funciones. Y si sus identificadores son demasiado largos, puede hacer que leer su código sea muy difícil. Las personas generalmente reconocen las palabras como unidades individuales; no leen todos los caracteres uno por uno, pero observan la forma general de la palabra. Los identificadores largos son más difíciles de distinguir de esta manera, y generalmente si son tan largos, contienen información redundante o repetitiva.

Ahora, aunque todavía es una buena práctica mantener el código por debajo de 80 columnas, esta no es una de esas reglas que debe seguirse religiosamente, contorsionándose para hacer que una línea encaje cuando simplemente no es así. Le sugiero que intente mantener todo su código en 80 columnas, pero cuando simplemente no encaja, no se preocupe demasiado.

Brian Campbell
fuente
3
Convenido. Sin embargo, a veces se alientan los identificadores largos (mediante pautas de codificación como "usar nombres significativos" o "evitar abreviaciones crípticas") o necesarios (como std::vector<...>::const_iterator), aunque en el último caso, las cosas pueden aliviarse con typedefs.
musiphil
Grandes razones No estoy seguro de que la longitud exacta de la línea sea importante, siempre y cuando su equipo (¿o lista de correo?) Lo acepte. Personalmente, voy con la sugerencia del tío Bob de nunca exceder los 120 caracteres.
Allan
1
@musiphil Sí, por eso incluí el último párrafo. Me he encontrado con líneas en C ++ donde simplemente no podía ajustar el nombre de la clase, el nombre del método y el tipo de retorno en una línea de 80 columnas al declarar el método. En lugar de hacer un salto de línea realmente extraño, es mejor simplemente romper la regla de 80 columnas (o 100 columnas) para esa línea.
Brian Campbell
46

Si mantengo mis líneas a menos de aproximadamente 100 caracteres, puedo tener dos ventanas de editor una al lado de la otra en un monitor de pantalla panorámica. Es muy útil tener tanto el archivo de encabezado de clase como la implementación visibles al mismo tiempo, o tener un código en un lado que invoca el código en el otro. Y, si mantengo las líneas cortas, no necesito una barra de desplazamiento horizontal en las ventanas de mi editor, lo que me da más espacio vertical.

80 caracteres pueden estar desactualizados, pero hay algún mérito en mantener las cosas dentro de lo razonable.

Niall C.
fuente
1
+1, con frecuencia abro varios archivos de origen lado a lado en Vim u otros editores. Con una fuente suficientemente pequeña y un margen derecho razonablemente estrecho, puedo obtener rápidamente una buena visión general del proyecto e incluso abrir mucha documentación.
greyfade
44
80 caracteres sigue siendo relevante porque muchas personas prefieren tener sus terminales y editores tan anchos; por lo tanto, si se limita a 80, será amigable con esas personas, en lugar de exigirles que reorganicen todas sus ventanas o que se ocupen del ajuste de línea o el desplazamiento horizontal.
Brian Campbell
1
80 caracteres todavía es razonable; ir más allá de eso fomenta el código anidado en exceso (¡en lugar de refactorizar!) y tener muchas ventanas juntas es excepcionalmente útil. ¡Agregar otro monitor solo aumenta la cantidad de ventanas que puede ver a la vez!
Donal Fellows
1
80 es amigable para VMS tal vez. Perdona mi pensamiento de la nueva era pero deberíamos extender el límite siempre que sea posible y mantenerlo donde sea necesario ..
Ross
29

No creo que el monitor tenga nada que ver con eso, al menos ya no.

Si no puede codificar una línea en 80 caracteres, de todos modos, probablemente sea un signo de código incorrecto. Expresiones demasiado complejas. Sangría demasiado profunda. etc. Debe detenerse y repensar lo que está haciendo.

Pero si está seguro de que el código requiere más de 80 líneas, continúe y hágalo. Creo que es mejor tener un código que supere los 80 caracteres que agregar cambios idiomáticos solo para hacerlo más pequeño.

Personalmente odio este tipo de cosas:

ret = my_function(parameter1, \
                  parameter2, \
                  parameter3, parameter4);

En lugar de simplemente:

ret = my_function(parameter1, parameter2, parameter3, parameter4);
Cesar Canassa
fuente
55
Seguramente si la línea 3 en el primer ejemplo no es demasiado larga, la línea 2 se puede combinar en la línea 1, lo que hace que parezca mucho más legible. (¿Qué idioma requiere líneas nuevas escapadas entre paréntesis?)
1
Ahh, eso es solo un pseudocódigo que escribí. Pero creo que C lo requiere.
Cesar Canassa
44
Solo en definiciones de macro de varias líneas, que son (o deberían ser) raras. Afecta significativamente la elección de la longitud máxima de la línea (mantener esas barras invertidas no es divertido), así que tengo curiosidad por qué lo muestra. Parece ser un hombre de paja ?
2
Si me tomo la molestia de romper una línea en una llamada de función, pondría cada parámetro en su propia línea, sangrado por un nivel.
Starblue
20

A la codificación?

Ciertamente si. El ser humano normal no puede leer muy bien. Con pocas columnas mueves menos los ojos, te enfocas mejor y retrasas el cansancio. Es una ganancia mínima pero importante.

Maniero
fuente
3
Si bien creo que el código es muy diferente de la prosa, es agotador leer código que periódicamente (es decir, la prosa generalmente sería mucho más consistente) extiende las líneas a más de 120 columnas.
6

Sí, hay razones para limitar la longitud de la línea de código:

  1. Aunque nuestras pantallas se han ensanchado, a veces necesita imprimir su código. Si solo por esta razón .
  2. Los visualizadores de diferencias a menudo muestran líneas con una división vertical; esto se vuelve más difícil si las líneas son tan largas como lo permitiría una pantalla panorámica.

Dicho esto, 80 es un poco demasiado pequeño. Pero, aún así, alguna limitación es probablemente una buena idea como principio de diseño.

Yo diría que las líneas extra largas no deben ser rechazadas, porque ocasionalmente son necesarias. Pero si la mayoría de las funciones solo se pueden ver en una pantalla de 30 ", entonces el código tiene algunos problemas.

Assaf Lavie
fuente
5

Es arbitrario, pero hay un límite no arbitrario para lo que es fácil de leer. Encuentro que las columnas de texto súper anchas son muy difíciles de escanear y leer, independientemente de si son código o prosa. Además, como han señalado muchas otras respuestas, no es como si este código fuera a ser lo único en su pantalla. Es genial tener dos o más ventanas de código abiertas al mismo tiempo y que quepan en un monitor de pantalla ancha.

jerwood
fuente
3

Probablemente no sea relevante elegir exactamente un límite de 80 caracteres; ¿Qué cambiaría si el límite es 85, por ejemplo?

Es cierto que los monitores utilizados hoy en día tienen resoluciones más altas, pero en un editor de texto / IDE, no todo el espacio se toma de la vista de texto; en el editor que uso muestra a la izquierda la lista de los archivos incluidos en el proyecto.

La resolución utilizada en una netbook o una notebook no es la misma que se usa en los monitores; Probablemente tenga sentido usar un límite de caracteres que no cree "problemas" para nadie.

kiamlaluno
fuente
55
¡80 caracteres era el límite estricto del número de columnas en la tarjeta perforada!
ChrisF
55
No importa cuál sea el estándar, pero si todos trabajan con el mismo estándar, eso hace la vida más fácil.
Skilldrick
2

Realmente depende del entorno de desarrollo.

Por ejemplo, en una gran corporación con miles de desarrolladores, probablemente haya cientos de personas que, en el transcurso de la vida de un producto, tendrán que mirar alguna parte de su código. Con tanta gente, seguramente habrá unos pocos que, por cualquier razón (hardware antiguo, netbooks, etc.) están operando a 800x600 o menos. Hay algún valor para acomodarlos.

Sin embargo, en mi compañía de 25 personas, digo que se joda. Todos usamos monitores modernos duales con la resolución máxima: 120-140 o más, es la guía informal.

Fishtoaster
fuente
2

Tener cierto límite ciertamente tiene sentido. Pero el límite de 80 caracteres es demasiado restrictivo. Prefiero algo como el límite de 96 caracteres. Es lo suficientemente ancho para la mayoría del código con el que tengo que lidiar y es lo suficientemente angosto para que dos archivos se puedan poner uno al lado del otro para diferirlos (en una pantalla panorámica).

Creo que la legibilidad del código supera a todas las demás preocupaciones. Y con 96 caracteres por código de línea se puede hacer mucho más legible que con 80.

No creo que la mayoría de las personas establezca sus terminales en 80 caracteres de ancho, no que las impresoras tengan que ajustar líneas de más de 80 caracteres. No es un límite difícil como solía ser en el pasado (distante). Puede configurar fácilmente el terminal y el ancho de la impresora a 100 caracteres.

alexeiz
fuente
1

No, ya no es relevante:

  • La mayoría de las fuentes utilizadas en aplicaciones y en la web no son de ancho fijo de todos modos. En otras palabras, 80 caracteres! = 80 caracteres.
  • Como dijiste, los anchos de pantalla han cambiado: 80 caracteres no es un límite sensible.

80 caracteres fue realmente una guía para las fuentes de ancho fijo en un entorno de consola.

Por supuesto, si todavía está utilizando una fuente de ancho fijo en un entorno de consola ... entonces, claro, 80 caracteres es sensato :)

Damovisa
fuente
3
Estoy bastante seguro de que se refería al uso de un límite de 80 caracteres en el código fuente, que se muestra casi universalmente en fuentes monoespaciadas.
Fishtoaster
1
Hmm ... en ese caso ... todavía no, pero por otras razones :)
Damovisa
1
¡80 caracteres era el límite estricto del número de columnas en la tarjeta perforada!
ChrisF
0

Si usa un editor en una GUI, los 80 caracteres por línea son irrelevantes, ya que la mayoría de los editores decentes, por ejemplo Notepad ++, tienen un botón para alternar el ajuste de línea. Con eso, no debería ser un problema, incluso al ver el código en una ventana delgada.

Lajos Meszaros
fuente