code readability - tag - ¿Estudios sobre el ancho de código óptimo?

html detail tag (10)

A mi leal saber y entender, los 80 caracteres se usan como estándar de codificación para mantener la compatibilidad con los editores de línea de comando (el ancho predeterminado de los terminales es típicamente de 80 caracteres). Con los IDEs modernos y las resoluciones de pantalla grandes, 80 caracteres probablemente no sean "óptimos", pero para muchos desarrolladores es esencial mantener la legibilidad en el terminal. Por esa razón, no es probable que el ancho de 80 caracteres sea reemplazado como el estándar de facto para el ancho del código pronto. Y para responder a su pregunta final, sí, el ancho del código, así como cualquier otra característica que afecte la legibilidad de su código, debe abordarse en sus estándares de codificación.

Si habilita el "Margen derecho de vista" en su IDE de elección, es probable que tenga un valor predeterminado de 80 caracteres. Tiendo a cambiarlo a 120 sin ninguna otra razón que no sea el estándar en una empresa con la que estuve hace unos años, y ninguna otra compañía me ha dicho que lo haga de manera diferente.

Mi pregunta es, ¿hay algún estudio que demuestre que 80 caracteres son el ancho máximo óptimo para la legibilidad del código, o es este valor simplemente "así ha sido siempre" y nadie sabe realmente por qué es así? Y, ¿debería ser el ancho de una línea de código parte de su estándar de codificación?

Como algunas personas han señalado en otras respuestas, la razón del límite de 80 caracteres es en parte histórica (tarjetas perforadas, pantallas pequeñas, impresoras, etc.) y parcialmente biológica (para rastrear en qué línea se encuentra generalmente es bueno poder ver la totalidad línea sin necesidad de girar la cabeza).

Dicho esto, recuerda que todavía somos humanos y que construimos herramientas para resolver nuestras propias limitaciones. Te propongo que ignores todo el debate sobre la limitación de caracteres y simplemente escribas cosas que tengan sentido independientemente de su extensión, y utilizas un IDE o editor de texto que puede ayudarte a seguir las líneas correctamente. Utilizando el mismo argumento para la sangría en el debate tabulaciones vs espacios, así como el ancho de las sangrías, propongo que utilices un marcador de sangría (más comúnmente la pestaña) y simplemente haz que las personas configuren su propio IDE o editores de texto para mostrarlos como les parezca más cómodo.

Seguir con un número fijo de caracteres por línea siempre empeorará las cosas para todos menos para el público objetivo. Dicho eso, si nunca compartirás el código, nunca; entonces realmente no hay razón para siquiera tener esta discusión, para empezar. Si desea compartir el código, probablemente debería dejar que las personas decidan por sí mismas lo que quieren, en lugar de forzar sus ideales (o los de otros) sobre ellos.

En realidad, la cosa de las 80 columnas precede mucho al DOS. Viene de los golpes de tarjeta, que eran dispositivos de 80 columnas.

Y para responder a la pregunta del OP, un "estudio" ha estado ocurriendo durante unos 600 años: el libro impreso. Estos han evolucionado a lo largo de los siglos, teniendo en cuenta la capacidad de lectura, en la posición en la que nos encontramos ahora, donde la longitud de línea promedio para el texto es de alrededor de 60 caracteres. Entonces, para la legibilidad, busque márgenes más estrechos.

La opción del margen derecho tiene la intención de mostrarle el ancho de la página si va a imprimir el código, y en su publicación anterior dijo que estaba configurada en 80 porque esa es la longitud de la línea históricamente anterior a la GUI hasta el final. tarjetas.

Recientemente, he visto una recomendación en un blog (no puedo recordar qué blog) para aumentar el tamaño de la fuente IDE para mejorar la calidad del código, la lógica detrás de esto es que si menos código cabe en la pantalla escribirás líneas más cortas y funciones shouter.

En mi opinión, las líneas más cortas hacen que leer el código y depurarlo sea más fácil, así que trato de mantener las líneas cortas, si tiene que establecer un límite para escribir mejor código y luego elegir lo que funciona para usted, también si es más productivo con las líneas más largas se sienten libres para aumentar el tamaño de la página y el código solo en pantallas anchas.

No tengo estudios, pero relataré mi experiencia.

Me parece que el desplazamiento horizontal es tedioso cuando se trata de texto. Miro el entorno en el que se usará el código y establezco estándares de ancho basados en ese contexto.

Por ejemplo, cuando trabajé en Emacs en XWindows, funcionó bien tener 2 ventanas de Emacs una al lado de la otra en todo momento. Eso los limitaba a 80 caracteres, así que esa era mi longitud máxima de línea.

En un momento dado trabajé en Visual Studio en una pantalla de 1920x1200. Lo mantendría maximizado, con todas las ventanas de herramientas ancladas hacia un lado. Había espacio suficiente para dos ventanas del editor, una al lado de la otra, en torno a 100 caracteres.

También encuentro que las líneas más largas provienen de llamadas a métodos con largas listas de parámetros . Esto a veces es un olor a código : quizás el método debe ser refactorizado .

Si usted y sus co-programadores tienen pantallas de alta resolución y buena vista, use una fuente pequeña y líneas largas. Por el contrario, puede necesitar líneas cortas.

Normalmente uso 120-150 a menos que la compañía describa lo contrario. Sin embargo, también depende del tipo de código:

Yo (casi) nunca uso declaraciones múltiples en una línea
Solo uso líneas largas (> 12) solo si las líneas que parecen similares pueden alinearse y no romperse.
Siempre uso suficientes espacios / paréntesis, etc.
Prefiero nombres de variables más largas que nombres más cortos

Hasta hace unos años, limitaba a 100, pero ahora las pantallas panorámicas se usan normalmente y los monitores de alta resolución 120 se pueden ver incluso en computadoras portátiles (que apenas uso).

Comparar una pantalla con un libro no es realmente bueno porque un libro tiene más espacio vertical y una pantalla tiene más espacio horizontal. Siempre trato de mantener una función máxima. una pantalla visible de largo.

Quizás los 80 caracteres también sean un buen punto para evitar estas cadenas de getter mal:

object.getFoo().getBar().getFooBar().get ...

si lo limitas a 80 caracteres, tal vez alguien localice estas variables y haga una comprobación nula, etc., pero tal vez la mayoría de los programadores les dejen envolver en la siguiente fila. no lo sé

Además de eso, 80 caracteres son geniales como se mencionó. Esto definitivamente debe estar dentro de los estándares de codificación.

Recuerdo claramente haber leído en alguna parte (creo que fue en la Documentación Ágil ) que para una legibilidad óptima, el ancho de un documento debería ser de dos alfabetos, o 60-70 caracteres. Creo que el ancho de la línea de los antiguos terminales proviene en parte de esa vieja regla tipográfica.

Sin tener en cuenta las restricciones de hardware y las diferencias en la forma de leer el código en comparación con el lenguaje natural, veo tres razones principales para limitar las líneas a alrededor de 80 caracteres.

Los globos oculares humanos son redondos, no muy angostos y anchos, y la mayor parte de su resolución está en el medio . Al leer durante horas, es mucho más cómodo barrer los ojos en arcos cortos, usando una barra de desplazamiento según sea necesario. No sé de un estudio formal específico para la legibilidad del código, pero de mis propias observaciones, con el monitor a 2 pies de distancia, con texto de tamaño en una fuente monoespaciada de 10 pt, 100 caracteres ocupan aproximadamente 1/3 de mi campo horizontal de visión, o alrededor de 60 grados ( fuera de los 30 grados más o menos donde está toda la resolución de nuestros ojos ).
La mayoría de las personas usa un monitor grande en el trabajo para que puedan ver muchas cosas sin hacer clic, no para que puedan ver una cosa realmente grande.
Las líneas más cortas contienen menos complejidad, lo que con suerte obliga a un desarrollador a dividir su código en unidades más digeribles.

Tenga piedad de los programadores que tienen que mantener su software más tarde y mantener un límite de 80 caracteres.

Razones para preferir 80:

Legible con una fuente más grande en computadoras portátiles
Deja espacio para poner dos versiones una al lado de la otra para comparar
Deja espacio para vistas de navegación en el IDE
Imprime sin romper líneas arbitrariamente (también se aplica al correo electrónico, páginas web, ...)
Limita la complejidad en una línea
Limita la sangría que a su vez limita la complejidad de los métodos / funciones

Sí, debería ser parte del estándar de codificación.