Hay una razón válida para el cumplimiento de una anchura máxima de 80 caracteres en un archivo de código, en este día y edad?[cerrado]

https://stackoverflow.com/questions/110928

02-07-2019
|

Pregunta

En serio.En un monitor de 22", que sólo cubre tal vez un cuarto de la pantalla.Necesito un poco de munición para el hacha de abajo de esta regla.

No estoy diciendo que no debería haber un límite;Sólo estoy diciendo, 80 caracteres es muy pequeña.

Solución

Creo que la práctica de guardar el código a 80 (79) columnas fue creado originalmente para apoyar a las personas de la edición de código en 80 columnas terminales tontas o en 80 columnas impresiones.Aquellos requisito en su mayoría han ido ahora, pero todavía hay razones válidas para mantener la columna 80 regla:

Para evitar envolver al copiar el código en el correo electrónico, páginas web y libros.
A la vista de múltiples fuentes de windows side-by-side o el uso de un side-by-side visor de diferencias.
Para mejorar la legibilidad.Estrecho de código puede ser leído rápidamente, sin tener que escanear sus ojos de lado a lado.

Creo que el último punto es el más importante.Aunque la muestra han crecido en tamaño y resolución en los últimos años, los ojos no.

Otros consejos

El origen de 80 columnas de formato de texto es anterior a 80 columnas terminales de la IBM de tarjetas perforadas, se remonta a 1928!Esto es una reminiscencia de la (apócrifo) la historia que NOS ferrocarril calibre se determina por el ancho de carro de ruedas en gran Bretaña Romana.

A veces me parece un poco restrictivo, pero tiene sentido tener algunos límite estándar, de modo que el 80 columnas es.

Aquí está el mismo tema tratado por el Slashdot.

Y aquí está una de la vieja escuela Fortran Declaración:

80 caracteres es un ridículo límite de estos días.Dividir las líneas de código donde tiene sentido, y no de acuerdo a cualquier límite de caracteres.

Sólo debe hacerlo por el bien de todos los que no tienen un 22 pulgadas de monitor de pantalla ancha.Personalmente, yo trabajo en una de 17 pulgadas 4:3 del monitor, y me parece que más que suficientemente amplia.Sin embargo, también tengo 3 de los monitores, así que todavía tienen un montón de espacio de espacio de la pantalla.

No sólo eso, sino que el ojo humano tiene realmente problemas de lectura de texto si las líneas son demasiado largas.Es demasiado fácil perderse en la línea que usted está en.Los periódicos son de 17 pulgadas de ancho (o somethign así), pero no los ves de escribir todo el camino a través de la página, lo mismo va para las revistas y otros elementos impresos.Es realmente sencillo de leer, si se mantienen las columnas estrechas.

Impresión de un solo espacio de la fuente en tamaño predeterminado es (en papel A4) 80 columnas por 66 líneas.

Cuando se tiene una secuencia de instrucciones que se repiten con pequeñas variaciones, puede ser más fácil ver las similitudes y diferencias si el que se agrupan en líneas de manera que las diferencias alinear verticalmente.

Yo diría que la siguiente es mucho más legible que habría sido si yo sería dividido en varias líneas:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

Actualización: En el comentario se ha sugerido que esta sería una forma más sucinta manera de hacer lo anterior:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY;

aunque ahora cabe en 80 columnas, creo que mi punto sigue en pie y me acaba de recoger un mal ejemplo.Aún así demostrar que la colocación de varias instrucciones en una línea que puede mejorar la legibilidad.

Yo uso el de la ventaja más grande que las pantallas de varios fragmentos de código próximos uno al otro.

Usted no recibirá ninguna munición de mí.De hecho, no me gustaría ver que ha cambiado desde que en situaciones de emergencia todavía veo raros casos donde tengo que cambiar el código a partir de un texto en la consola.

Super-líneas largas son más difíciles de leer.Sólo porque usted puede conseguir 300 caracteres a través de su monitor no significa que usted debe hacer que las líneas de largo.300 personajes también es muy complejo para una declaración, a menos que usted no tiene ninguna opción (una llamada que necesita un montón de parámetros.)

Yo uso el 80 caracteres como una regla general, pero voy a ir más allá de que si la aplicación podría significar poner un salto de línea en una localización indeseable.

La única cosa que cumplir para permanecer dentro de 80 caracteres es mi comentario.

Personalmente...me estoy dedicando todo mi poder del cerebro (lo poco que hay) para la codificación de derecho, es un dolor tener que volver y romper todo, hasta en el 80 char límite, cuando podría estar gastando mi tiempo en la próxima función.Sí, Resharper podría hacer por mí supongo, pero luego me asusta un poco que una 3ra parte del producto es la toma de decisiones en mi código de diseño y cambios ("por Favor, no rompas mi código en dos líneas de HAL.HAL?").

Dicho esto, yo trabajo en un pequeño equipo y todos nuestros monitores son bastante grandes así que preocuparse de lo que molesta a mis compañeros programadores no es una gran preocupación en la medida en que va.

Parece que a pesar de que algunos idiomas animar a más líneas de código para el bien de los más explosión para el buck (corto la mano si luego de las declaraciones).

Yo tengo dos de 20" 1600x1200 monitores y me pego a 80 columnas porque me permite mostrar varios editor de texto de windows side-by-side.El uso de la '6x13 fuente (la trad.xterm fuente) 80 columnas tomar hasta 480 píxeles, además de la barra de desplazamiento y los bordes de las ventanas.Esto permite tener tres ventanas de este tipo en un 1600x1200 monitor.En windows la fuente Lucida Console realmente no hacerlo (el mínimo tamaño utilizable es de 7 píxeles de ancho), pero un 1280x1024 monitor mostrará dos columnas y una 1920x1200 monitor como un HP LP2465 se mostrará 3.También se deja un poco de espacio en el lado de los diversos explorer, propiedades y otros de windows desde Visual Studio.

Además, muy largas líneas de texto es difícil de leer.Para el texto de la óptima es de 66 caracteres.Hay un punto donde excesivamente largo identificadores de empezar a ser contraproducente porque hacen que sea difícil de establecer, con código de forma coherente.Buen diseño y sangría proporciona señales visuales en cuanto a la estructura del código y algunos lenguajes (Python viene a la mente) el uso de la sangría explícitamente para ello.

Sin embargo, El estándar de bibliotecas de clases de Java y .Net tienden a tener una preponderancia de muy largo identificadores para uno no necesariamente garantiza a ser capaz de hacer esto.En este caso, la imposición de código con saltos de línea todavía ayuda a hacer que la estructura explícita.

Tenga en cuenta que usted puede obtener las versiones de windows de '6x13' fuentes Aquí.

Las otras respuestas ya suman las cosas bien, pero también vale la pena teniendo en cuenta que es posible que desee copiar y pegar el código en un correo electrónico, o si no el código, a continuación, un diff.

Que en un momento de tener un "ancho máximo" es útil.

No eres la única persona que se va a mantener el código.

La siguiente persona que no puede tener a una de 17" de pantalla o puede ser que necesite fuentes grandes para leer el texto.El límite tiene que ser en algún lugar y 80 caracteres es la convención debido a la pantalla anterior limitaciones.Puede usted pensar en alguna nueva norma (120) y por qué es una buena idea usar que otros, a continuación, "que es lo que cabe en mi monitor, en Xpt fuente?"

Recuerde, siempre hay excepciones a la regla, por lo que tiene una determinada línea o un bloque de código que tiene sentido ser de más de 80 caracteres, a continuación, ser un rebelde.

Pero tomar el tiempo para pensar "es este código tan mal que no puede vivir dentro de 80 caracteres?"

En el Linux estándar de codificación, no sólo mantener el 80 límite de caracteres, pero también el uso de 8 espacio de sangría.

Parte del razonamiento es que si llegas a la margen derecha, debe considerar el movimiento de un nivel de sangría en una función separada.

Esto hará que un código más claro, porque independientemente de la sangría de las longitudes, es más difícil leer el código con muchas estructuras de control anidadas.

Me pregunto si esto podría causar más problemas en este día y edad.Recuerde que en C (y posiblemente otros idiomas) hay reglas por cuánto tiempo el nombre de una función puede ser.Por lo tanto, a menudo se ve muy difícil de comprender, los nombres en código C.Lo bueno es que no ocupan mucho espacio.Pero cada vez que lo miro de código en algún lenguaje como C# o Java el método a menudo los nombres son muy largos, lo que hace que sea casi imposible mantener su código en un 80 caracteres de longitud.No creo que el 80 caracteres son válidos hoy en día, a menos que usted necesita para ser capaz de imprimir el código, etc.

Como otros han dicho, creo que es mejor para (1) la impresión y (2) mostrar varios archivos en paralelo verticalmente.

Me gusta el límite de mi ancho de 100 caracteres o menos para permitir que dos SxS editores en un monitor de pantalla ancha.No creo que hay alguna buena razón para un límite de exactamente 80 caracteres más.

He ampliado mi código a 100 personajes que se adapta cómodamente en menos de la mitad de mi pantalla de mi Macbook.120 caracteres es probablemente el límite antes de que las líneas comienzan a llegar demasiado largo y complejo.Usted no quiere quedar demasiado amplia, otra cosa que fomentar compuesto de declaraciones y profundamente estructuras de control anidadas.

El margen derecho es la naturaleza la manera de decirle a realizar una extra método de refactorización.

El uso de las fuentes proporcionales.

Lo digo en serio.Por lo general se puede obtener la equivalencia de 100-120 caracteres en una línea sin sacrificar la legibilidad o la capacidad de impresión.De hecho, es incluso más fácil de leer con una buena fuente (por ejemplo, Verdana) y el coloreado de la sintaxis.Se ve un poco extraño para un par de días, pero rápidamente te acostumbras a él.

La gente dice largas líneas de código tienden a ser complejos.Considere la posibilidad de una simple clase de Java:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Este es el 94 caracteres y el nombre de la clase es bastante corto (por GWT normas).Sería difícil de leer en 2 líneas y es muy legible en una línea.La pragmática al respecto y permitir así el "compatibilidad hacia atrás", yo diría que el 100 caracteres es el ancho de la derecha.

Como el autor de las directrices de codificación para mi empleador me han subido la longitud de la línea de 80 a 132.¿Por qué este valor?Bien, al igual que otros señalaron, 80 es la longitud de muchos de los viejos hardware de los terminales.Y 132 es así! Es el ancho de la línea cuando los terminales están en amplia modo.Cualquier impresora podría también hacer copias impresas en gran modo con un condensado de la fuente.

La razón por la que no se alojen en el 80 es el que mejor me

prefieren más nombres con un significado para los identificadores
no se moleste con las definiciones de tipos de estructuras y enumeraciones en C (que son MALOS, que OCULTAN información útil!Pregunta a Peter van der Linden en "Profundo C Secretos" si usted no me cree), por lo que el código tiene más struct FOO func(struct BAR *aWhatever, ...) que el código de typedef fanáticos.

y en virtud de estas reglas, a solo 80 caracteres/línea causa feo línea ajusta más a menudo de lo que mis ojos considere aceptable (sobre todo en los prototipos y las definiciones de función).

Yo trato de mantener las cosas de abajo, cerca de 80 caracteres por una simple razón:mucho más que eso significa que mi código está volviendo demasiado complicado.Excesivamente detallado de la propiedad/método de nombres, nombres de clases, etc.causar tanto daño como breves.

Soy ante todo un programador Python, por lo que este produce dos conjuntos de limitaciones:

No escribir largas líneas de código
No guión demasiado

Cuando usted comienza a llegar a dos o tres niveles de sangría, su lógica se presenta confuso.Si usted no puede mantener un solo bloque en la misma página, el código es demasiado complicado y difícil de recordar.Si usted no puede mantener una sola línea dentro de 80 caracteres, su línea es llegar demasiado complicado.

Es fácil en Python para escribir relativamente concisa código (ver codegolf) en detrimento de la legibilidad, pero es aún más fácil escribir detallado código en detrimento de la legibilidad.Métodos auxiliares no son una mala cosa, ni son clases auxiliares.El exceso de abstracción puede ser un problema, pero ese es otro reto de la programación.

Cuando en duda, en un lenguaje como C escriba funciones de ayuda en línea y si usted no quiere que la sobrecarga de llamar a otra función y saltar de nuevo.En la mayoría de los casos, el compilador va a manejar las cosas de forma inteligente para usted.

Ya hay un montón de buenas respuestas a esta, pero vale la pena mencionar que en el IDE usted podría tener una lista de archivos a la izquierda, y una lista de funciones a la derecha (o cualquier otra configuración).

Estás código es sólo una parte del medio ambiente.

La cosa I no cumplir 80 caracteres significa que, finalmente, el ajuste de línea.
De la OMI, cualquier longitud elegido para un max-width línea no es siempre apropiado y el ajuste debe ser una respuesta posible.
Y que no es tan fácil como parece.

Se implementa en jedit
_{(fuente: jedit.org)} que ofrece word wrap

Pero es amargamente se perdió en el eclipse de muuuucho tiempo !(desde el año 2003, de hecho), principalmente debido a un ajuste el editor de texto implica:

Envuelve la línea de información para el visor de texto, código de la navegación, las reglas vertical.
Sin envolver la línea de información es necesaria para funcionalidades como ir a la línea, la línea de la numeración de la regla de la columna, línea actual resaltar, guardar el fichero.

De hecho sigo una regla similar para mi propio código, pero sólo porque de impresión de código de una página A4 - 80 columnas es de aproximadamente el ancho de la derecha para mi tamaño de fuente deseado.

Pero eso es preferencia personal y, probablemente, no lo que fueron después (ya que quieres munición para ir en el otro sentido).

Lo que no se pregunta el razonamiento detrás de la límite - en serio, si nadie puede venir para arriba con una buena razón de por qué es así, usted tiene un buen caso para eliminarlo de los estándares de codificación.

Estoy distinción de lado a lado todo el día y no tengo un puto' 22 pulgadas de monitor.No sé si alguna vez será.Esto, por supuesto, es de poco interés para escribir-sólo los programadores disfrutando de flecha-codificación y 300-char líneas.

Sí, porque incluso en este día y edad, algunos de nosotros en la codificación de los terminales (ok, la mayoría de los emuladores de terminal server), donde la pantalla puede mostrar sólo 80 caracteres.Así que, al menos para la codificación hago, realmente aprecio el 80 char regla.

Todavía creo que el límite no está limitada en la parte visual.Seguro, los monitores y resoluciones lo suficientemente grande como para mostrar aún más caracteres en una línea de hoy en día, pero hace aumentar la legibilidad?

Si el límite es realmente forzada es también una buena razón para volver a pensar en el código y no poner todo en una línea.Es lo mismo con sangría - si usted necesita mucho de los niveles de su código necesita ser re-pensado.

Romper a los 80 caracteres, es algo que se puede hacer mientras la codificación, no después.Mismo con los comentarios, por supuesto.La mayoría de los editores pueden ayudar a ver donde el 80 caracteres límite.

(Esto puede ser un poco OT, pero en Eclipse hay una opción que formatea el código al guardar (de acuerdo con cualesquiera reglas que usted desea).Esto es un poco extraño al principio, pero después de un tiempo empiezas a aceptar que el formato no es más en sus manos que el código generado es.)

Si tuviéramos uno de estos, no estaríamos teniendo esta discusión!;-)

Pero en serio los problemas que la gente ha planteado en sus respuestas son totalmente legítimos.Sin embargo, el cartel original no estaba argumentando en contra de un límite, simplemente que el 80 de las columnas es de muy pocos.

La cuestión de correo electrónico fragmentos de código tiene algún mérito.Pero teniendo en cuenta el mal de las cosas que la mayoría de clientes de correo electrónico de hacer el pre-texto con formato, creo que la línea de ajuste es sólo uno de sus problemas.

Como para la impresión por lo general encontramos que el 100 líneas de caracteres se muy cómodamente caben en una página impresa.

Intento mantener mis líneas por debajo de 80 columnas.La razón principal es que a menudo me encuentro con grep y less para examinar mi código cuando se trabaja en la línea de comandos.En realidad no me gusta cómo los terminales están rompiendo las largas líneas de código fuente (que después de todo no están hechos para el trabajo).Otra razón es que me parece que se ve mejor si todo encaja en la línea y no está rota por el editor.Por ejemplo, tener parámetros de tiempo de las llamadas de función perfectamente alineados por debajo de cada uno de los otros y cosas similares.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow