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

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?

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.