¿Estudios sobre ancho de código óptimo?


131

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?


1
Si bien no conozco ningún estudio, encontrará muchas opiniones como respuestas a esta pregunta: * ¿Existe una razón válida para imponer un ancho máximo de 80 caracteres en un archivo de código, hoy en día?
Adam Bellaire

3
No hay estudios que conozca, pero puede que le resulte interesante observar diferentes estándares de codificación de proyectos. Por ejemplo, Google tiene 80 caracteres. ( code.google.com/p/google-styleguide ) donde como WebKit (¿ala Apple's?) no tienen límite AFAIK ( webkit.org/coding/coding-style.html ). Mozilla parece ser 80 ( developer.mozilla.org/En/Mozilla_Coding_Style_Guide#Line_length )
gman

Es la misma razón por la que deletreamos "burócrata" como lo hacemos. Porque hace mucho tiempo alguien definió un estándar por una razón que puede o no haber tenido sentido en ese momento. Por deletrear era una dudosa fascinación por el latín, por codificar el tamaño de una tarjeta perforada de papel. Entonces un método se etiquetó como "correcto". Y los pequeños burócratas han estado haciendo cumplir las normas desde entonces.
Aplicable el

Respuestas:


116

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.


85
Realmente no creo que se pueda comparar la lectura del lenguaje natural con la lectura de un lenguaje de programación en términos de usabilidad.
Frug

25
@Frug: en realidad, probablemente puedas. La razón del ancho de 65 caracteres no se debe a que las líneas más grandes no se pueden leer, sino que es un arco demasiado apretado cuando el ojo se mueve a la siguiente línea. Usted puede evitar esto mediante el aumento de altura de la línea, pero eso hace que sea más difícil de bloquear el uso espaciado a transmitir el significado, por lo que es probable que haya algo a evitar en un IDE.
Jimmy Breck-McKye

32
@ Jim: mi lenguaje natural no contiene palabras con 30 caracteres (no es que lo use de todos modos) y se analiza de manera completamente diferente a un lenguaje de programación. A menudo puede agrupar una línea de código como separada del resto, ya sea un condicional largo o una combinación de métodos y clases largos. Combine esto con la sangría y la comparación entre los dos idiomas se vuelve absurda. No tengo dudas de que alguien que estudie científicamente la legibilidad y la longitud de la línea se opondría a su lavado sobre las diferencias.
Frug

10
@Frug - Realmente no veo cómo sus objeciones se relacionan con ninguno de los reclamos que hice, pero puedo ver que la sangría rompe el modelo que estoy proponiendo. Sin embargo, no me llames 'Jim'.
Jimmy Breck-McKye

17
Un libro generalmente se coloca mucho más cerca de los ojos que un monitor, lo que significa que se permiten menos caracteres por línea si el lector puede leer el libro sin tener que estirar el cuello. Por lo general, una pantalla no se coloca a la distancia de un libro, lo que significa que se pueden usar más caracteres por línea mientras se mantiene dentro de los límites del ángulo máximo del ojo. Además, el código no se lee tanto como se lee detenidamente, lo que hace que este ancho sea menos importante. Yo (YMMV) puedo seguir fácilmente líneas con 120 caracteres de código en la pantalla de mi computadora portátil, pero esto es demasiado ancho para 2 buffers emacs en mi computadora portátil de 15 ", por desgracia.
Obscaenvs

104

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.


10
Estas son excelentes razones para mantener el ancho de línea a 80 caracteres o menos. Estoy realmente sorprendido (decepcionado) de que su respuesta, que está claramente pensada y correcta, no haya recibido más puntos. A esta lista, agregaría: (1) el desplazamiento horizontal no es divertido. (2) Puede aumentar considerablemente la densidad del código en el que está trabajando visualizando ese código en varias columnas. Una gran cantidad de bienes raíces se desperdicia cuando tiene algunas líneas que se extienden hacia la derecha cuando la mayoría de las otras líneas no lo hacen.
Donnie Cameron

44
ok, pero ¿qué sucede cuando hay un bloque de código con pocas hendiduras? eso me ha pasado y 80 personajes no son nada divertidos.
EKanadily

14
Limits the complexity in one lineNo estoy seguro de por qué es mejor distribuir la complejidad en varias líneas. Simplemente empuja más en tu pila mental.
Jonathan

44
Este es un tema muy antiguo. pero todavía está de acuerdo ahora que muchos desarrolladores usan monitores de 27 pulgadas :-). Quiero decir, si la vista es un problema, una pantalla más grande puede ayudar. Hace 8 años todavía estábamos trabajando en monitores de 17 o 20 pulgadas y algunos en resoluciones de 4: 3 incluso.
Mathijs Segers

1
@MathijsSegers, independientemente del tamaño o la resolución del monitor, es aún más cómodo mantener el texto dentro de los 30 grados intermedios de su campo de visión. Cuando trabajo con varias ventanas abiertas en monitores uno al lado del otro, tiendo a girar la cabeza para mirar de uno a otro. Una persona no debería tener que girar la cabeza o girar los ojos por completo para poder leer de un extremo a otro de la línea. Tanto la rotación rápida de los ojos o la cabeza probablemente causaría vértigo si se realiza todo el día.
maurice

41

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.


1
más uno para los "ojos agudos" porque realmente eso fue lo que pasó conmigo.
EKanadily

26

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.


66
¿Cómo funcionan 120-150 caracteres por línea con tener varias ventanas abiertas una al lado de la otra? ¿Mantiene abiertas muchas ventanas del editor de código una al lado de la otra? - En mi monitor de 30 '', puedo tener 3 ventanas una al lado de la otra, si limito mis líneas a 97 caracteres / línea.
KajMagnus

1
Codifico en una pantalla grande y también me gustan las cantidades más grandes. Apunto a 110-130. Uno de mis objetivos principales es la legibilidad y, en mi opinión, a veces es menos legible dividir las declaraciones en 2-3 líneas. A veces también voy a 500-1000 para ocultar la basura que no quiero ver, como algunos comentarios, código deshabilitado y algunos valores codificados. Creo que también depende del programador. Si la mayoría de los codificadores operan a 80, entonces es mejor apuntar a eso cuando se trabaja con código compartido.
Sunsetquest

10

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.


55
Para su información, el método excesivo de encadenamiento como este se conoce como el anti-patrón de choque de trenes .
Dennis

4

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.

3

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.


3

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.


1

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.


0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.