¿Estudios sobre ancho de código óptimo?

Si habilita la opción "Ver margen derecho" en su IDE de elección, es probable que tenga 80 caracteres por defecto. Tiendo a cambiarlo a 120 por ninguna otra razón que no sea el estándar en una compañía 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 muestre que 80 caracteres tengan el ancho máximo óptimo para la legibilidad del código, o este valor es solo "así ha sido siempre" y nadie sabe realmente por qué es así? Y, ¿el ancho de una línea de código debe ser parte de su estándar de codificación?

En realidad, la cosa de 80 columnas precede mucho a DOS. Proviene de golpes de tarjeta, que eran dispositivos de 80 columnas.

Y para responder a la pregunta del OP, un "estudio" ha estado sucediendo 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 estamos ahora, donde la longitud promedio de la línea para el texto es de alrededor de 60 caracteres. Entonces, para facilitar la lectura, elija márgenes más estrechos.

Ten piedad de los programadores que tienen que mantener tu software más tarde y mantenerte en 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 juntas para comparar

• Deja espacio para vistas de navegación en el IDE

• Imprime sin líneas de corte arbitrarias (también se aplica a 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.

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, ha funcionado bien para tener 2 ventanas de Emacs lado a lado en todo momento. Eso los limitó a 80 caracteres, así que esa fue la longitud máxima de mi línea.

En un momento trabajé en Visual Studio en una pantalla de 1920x1200. Lo mantendría maximizado, con todas las ventanas de herramientas acopladas a un lado. Quedaba espacio suficiente para dos ventanas del editor una al lado de la otra con alrededor de 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 es a veces un olor a código : quizás el método debería ser refactorizado .

Si usted y sus coprogramadores tienen pantallas de alta resolución y una vista nítida, utilice una fuente pequeña y líneas largas. Por el contrario, es posible que necesite 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 múltiples declaraciones 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 largos sobre nombres más cortos

Hasta hace unos años, me limitaba a 100, pero ahora normalmente se usan pantallas anchas 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 max. Una pantalla visible de largo.

Quizás los 80 caracteres también sean un buen punto para evitar estas malas cadenas de captación:

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

si lo limita a 80 caracteres, tal vez alguien localizaría estas variables y haría una verificación nula, etc., pero tal vez la mayoría de los programadores les dejarían pasar a la siguiente fila. no lo sé

Además de eso, 80 personajes son geniales como se menciona en Starblue. Esto debería entrar en los estándares de codificación.

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

1. Los globos oculares humanos son redondos, no realmente estrechos y anchos, y la mayor parte de su resolución está en el medio . Al leer durante horas a la vez, es mucho más cómodo barrer los ojos en arcos cortos, usando una barra de desplazamiento según sea necesario. No conozco un estudio formal específico sobre la legibilidad del código, pero según mis propias observaciones, con el monitor a 2 pies de distancia, con un tamaño de texto en una fuente monoespaciada de 10 puntos, 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á la resolución de todos nuestros ojos ).
2. La mayoría de las personas usan un monitor grande en el trabajo para poder ver varias cosas sin hacer clic de un lado a otro, no para poder ver una cosa realmente grande.
3. 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.

Recuerdo claramente haber leído en alguna parte (creo que estaba en la documentación ágil ) que, para una legibilidad óptima, el ancho de un documento debe ser de aproximadamente dos alfabetos, o 60-70 caracteres. Creo que el ancho de línea de las antiguas terminales provino en parte de esa vieja regla tipográfica.

La opción de margen derecho tiene la intención de mostrarle el ancho de la página si va a imprimir el código, y ha publicado anteriormente que dijo que estaba configurado en 80 porque esa era la longitud de la línea históricamente antes de la GUI hasta el final. tarjetas

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

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

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

Dicho esto, recuerda que aún somos humanos y creamos herramientas para resolver nuestras propias limitaciones. Le propongo que ignore todo el debate sobre la limitación de caracteres y simplemente escriba cosas que tengan sentido independientemente de su longitud, y use un IDE o editor de texto que pueda ayudarlo a realizar un seguimiento adecuado de las líneas. Utilizando el mismo argumento para la sangría en el debate de pestañas vs espacios, así como el ancho de las sangrías, propongo que use un marcador de sangría (más comúnmente la pestaña) y solo haga que las personas configuren su propio IDE o editores de texto para mostrarlos como les resulte más cómodo.

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

Que yo sepa, los 80 caracteres se usan como un estándar de codificación para mantener la compatibilidad con los editores de línea de comandos (el ancho de terminal predeterminado es típicamente 80 caracteres). Con IDEs modernos y resoluciones de pantalla grande, 80 caracteres probablemente no es "óptimo", 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 se reemplace como el estándar de facto para el ancho del código en el corto plazo. 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.