text-editor - programming - editorconfig vscode

¿Existe alguna razón válida para imponer un ancho máximo de 80 caracteres en un archivo de código este día y edad? (30)

80 caracteres es un límite ridículo en estos días. Divida sus líneas de código donde tenga sentido, no según ningún límite de caracteres arbitrario.

Seriamente. En un monitor de 22 ", solo cubre un cuarto de la pantalla. Necesito un poco de munición para rebajar esta regla.

No estoy diciendo que no debería haber un límite; Solo digo que 80 caracteres son muy pequeños.

Amplié mi código a 100 caracteres, que se ajusta cómodamente en menos de la mitad de mi pantalla en mi Macbook. 120 caracteres es probablemente el límite antes de que las líneas comiencen a ser demasiado largas y complejas. No desea ensancharse demasiado, puede alentar declaraciones compuestas y estructuras de control profundamente anidadas.

El margen derecho es la manera que tiene la naturaleza de decirle que realice una refactorización de método adicional .

Como autor de las pautas de codificación para mi empleador, he aumentado la longitud de la línea de 80 a 132. ¿Por qué este valor? Bueno, como otros señalaron, 80 es la longitud de muchos terminales de hardware antiguos. ¡Y 132 también! Es el ancho de línea cuando los terminales están en modo ancho . Cualquier impresora también podría hacer copias impresas en modo ancho con una fuente condensada.

El motivo para no quedarme en 80 es que prefiero

prefieren nombres más largos con un significado para identificadores
No te molestes con typedefs para estructuras y enumeraciones en C (son MALAS, OCULTAN información útil! Pregunta a Peter van der Linden en "Deep C Secrets" si no lo crees), entonces el código tiene más struct FOO func(struct BAR *aWhatever, ...) que el código de typedef fanatics.

y bajo estas reglas, solo 80 caracteres / línea causan envolturas feas de líneas más a menudo de lo que mis ojos consideran aceptables (principalmente en prototipos y definiciones de funciones).

Como han dicho otros, creo que es mejor para (1) imprimir y (2) mostrar varios archivos uno al lado del otro verticalmente.

Creo que la práctica de mantener el código en 80 (o 79) columnas se creó originalmente para ayudar a las personas a editar código en terminales tontas de 80 columnas o en impresiones de 80 columnas. Esos requisitos en su mayoría se han ido ahora, pero todavía hay razones válidas para mantener la regla de 80 columnas:

Para evitar envolver al copiar el código en el correo electrónico, páginas web y libros.
Para ver varias ventanas de origen una al lado de la otra o usar un visor de diferencias lado a lado.
Para mejorar la legibilidad El código estrecho se puede leer rápidamente sin tener que examinar los ojos de un lado a otro.

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

Cuando se tiene una secuencia de enunciados que se repiten con variaciones menores, puede ser más fácil ver las similitudes y diferencias si se agrupan en líneas para que las diferencias se alineen verticalmente.

Yo diría que el siguiente es mucho más legible de lo que hubiera sido si lo hubiera dividido en múltiples 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 concisa 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 acabo de elegir un mal ejemplo. Todavía demuestra que colocar múltiples declaraciones en una línea puede mejorar la legibilidad.

De hecho, sigo una regla similar para mi propio código, pero solo debido a la impresión de código en una página A4: 80 columnas tiene aproximadamente el ancho correcto para el tamaño de fuente que desee.

Pero eso es preferencia personal y probablemente no lo que buscabas (ya que quieres munición para el otro lado).

¿Qué no cuestiona el razonamiento detrás del límite? En serio, si nadie puede encontrar una buena razón por la que es así, tiene un buen argumento para que se elimine de sus estándares de codificación.

Deberías hacerlo por el bien de todos los que no tienen un monitor de pantalla ancha de 22 pulgadas. Personalmente, trabajo en un monitor 4: 3 de 17 pulgadas, y me parece más que suficientemente amplio. Sin embargo, también tengo 3 de esos monitores, por lo que todavía tengo mucho espacio de pantalla utilizable.

No solo eso, sino que el ojo humano tiene problemas para leer el texto si las líneas son demasiado largas. Es muy fácil perderse en la línea en la que se encuentra. Los periódicos tienen 17 pulgadas de ancho (o algo por el estilo), pero no los ve escribiendo en toda la página, lo mismo ocurre con las revistas y otros artículos impresos. En realidad es más fácil de leer si mantiene las columnas estrechas.

El origen del formato de texto de 80 columnas es anterior a los terminales de 80 columnas: ¡la tarjeta perforada de IBM data de 1928 ! Esto es una reminiscencia de la historia (apocryphal) que el ancho del ferrocarril de los Estados Unidos estaba determinado por el ancho de las ruedas de los carros en la Britania romana.

A veces me parece un poco restrictivo, pero tiene sentido tener un límite estándar, por lo que son 80 columnas.

Este es el mismo tema cubierto por Slashdot .

Y aquí hay una declaración Fortran de la vieja escuela:

En el estándar de codificación de Linux, no solo mantienen el límite de 80 caracteres, sino que también usan una sangría de 8 espacios.

Parte del razonamiento es que si alguna vez llega al margen derecho, debería considerar mover un nivel de sangría en una función separada.

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

Estoy diferiendo lado a lado todo el día y no tengo un maldito monitor de 22 pulgadas. No sé si alguna vez lo haré. Esto, por supuesto, es de poco interés para los programadores de solo escritura que disfrutan de codificación por flecha y líneas de 300 caracteres.

Imprimir una fuente monoespaciada en tamaños predeterminados es (en papel A4) de 80 columnas por 66 líneas.

Intento mantener las cosas cerca de los 80 caracteres por una simple razón: mucho más que eso significa que mi código se está volviendo demasiado complicado. Los nombres excesivamente detallados de propiedades / métodos, nombres de clases, etc. causan tanto daño como los más escuetos.

Principalmente soy un codificador de Python, por lo que esto produce dos conjuntos de limitaciones:

No escriba largas líneas de código
No aplicar demasiada sangría

Cuando comienzas a alcanzar dos o tres niveles de sangría, tu lógica se vuelve confusa. Si no puede mantener un solo bloque en la misma página, su código se está volviendo demasiado complicado y difícil de recordar. Si no puede mantener una sola línea dentro de los 80 caracteres, su línea se volverá demasiado complicada.

En Python es fácil escribir un código relativamente conciso (ver codegolf) a expensas de la legibilidad, pero es aún más fácil escribir código detallado a expensas de la legibilidad. Los métodos de ayuda no son algo malo, ni son clases de ayuda. La abstracción excesiva puede ser un problema, pero ese es otro desafío de la programación.

Cuando tenga dudas en un idioma como C, escriba funciones auxiliares y escríbalas si no quiere que se le ocurra una llamada a otra función y salte hacia atrás. En la mayoría de los casos, el compilador manejará las cosas inteligentemente para usted.

Intento mantener mis líneas debajo de 80 columnas. La razón más fuerte es que a menudo me encuentro usando grep y less para explorar mi código cuando trabajo en la línea de comandos. Realmente no me gusta cómo los terminales están rompiendo líneas de fuente largas (después de todo, no están hechas para ese trabajo). Otra razón es que me parece mejor si todo encaja en la línea y el editor no lo rompe. Por ejemplo, tener parámetros de llamadas a funciones largas muy bien alineados uno debajo del otro y cosas similares.

La gente dice que las largas líneas de código tienden a ser complejas. Considere una clase Java simple:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Tiene 94 caracteres y el nombre de clase es bastante corto (según los estándares GWT). Sería difícil leer en 2 líneas y es muy legible en una línea. Siendo pragmático al respecto y permitiendo así la "compatibilidad hacia atrás", diría que 100 caracteres tienen el ancho correcto.

Las líneas súper largas son más difíciles de leer. El hecho de que pueda obtener 300 caracteres en su monitor no significa que deba hacer que las líneas sean tan largas. 300 caracteres también es demasiado complejo para una declaración a menos que no tenga otra opción (una llamada que necesita un montón de parámetros).

Utilizo 80 caracteres como regla general, pero iré más allá si aplicarlo significaría poner un salto de línea en una ubicación indeseable.

Las otras respuestas ya resumieron las cosas muy bien, pero también vale la pena considerar cuándo es posible que desee copiar y pegar un código en un correo electrónico, o si no es el código, entonces un diff.

Ese es un momento en el que tener un "ancho máximo" es útil.

Lo único que hago para mantenerme dentro de los 80 caracteres es mi comentario.

Personalmente ... estoy dedicando todo mi poder cerebral (lo poco que hay) a la codificación correcta, es un dolor tener que volver y romper todo en el límite de 80 caracteres cuando podría estar pasando mi tiempo en la siguiente función . Sí, Resharper podría hacerlo por mí, supongo, pero luego me asusta un poco que un producto de terceros esté tomando decisiones sobre el diseño de mi código y lo cambie ("Por favor, no rompa mi código en dos líneas HAL. HAL?" )

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

Sin embargo, parece que algunos lenguajes alientan líneas de código más largas por el bien de más dinero por el dinero (declaraciones de mano corta si entonces).

Lo que no hago cumplir 80 caracteres significa finalmente el ajuste de palabras.
IMO, cualquier longitud elegida para una línea de ancho máximo no siempre es apropiada y el ajuste de palabras debería ser una posible respuesta.
Y eso no es tan fácil como parece.

Se implementa en jedit alt text http://www.jedit.org/images/logo64.png que ofrece un ajuste de palabras

¡Pero se echa de menos en eclipse desde hace mucho tiempo ! (desde 2003, de hecho), principalmente porque un ajuste de palabra para editor de texto implica:

La información de línea envuelta es para el visor de texto, navegación de código, reglas verticales.
La información de la línea desempaquetada se requiere para funcionalidades como ir a línea, columna de regla de numeración de línea, resaltado de línea actual, guardar archivo.

Me gusta limitar mi ancho a 100 caracteres o más para permitir dos editores SxS en un monitor de pantalla panorámica. No creo que haya ninguna buena razón para un límite de exactamente 80 caracteres más.

Me pregunto si esto podría causar más problemas en este día y edad. Recuerde que en C (y posiblemente en otros idiomas) existen reglas sobre cuánto tiempo puede ser el nombre de una función. Por lo tanto, a menudo se ven nombres muy difíciles de entender en el código C. Lo bueno es que no usan mucho espacio. Pero cada vez que miro el código en algún lenguaje como C # o Java, los nombres de los métodos suelen ser muy largos, lo que hace que sea casi imposible mantener el código con una longitud de 80 caracteres. No creo que los 80 caracteres sean válidos hoy, a menos que necesite imprimir el código, etc.

Romper a 80 caracteres es algo que haces durante la codificación, no después. Lo mismo con los comentarios, por supuesto. La mayoría de los editores pueden ayudarlo a ver dónde está el límite de 80 caracteres.

(Esto puede ser un poco de OT, pero en Eclipse hay una opción que formatea el código cuando lo guarda (de acuerdo con las reglas que desee). Esto es un poco extraño al principio, pero después de un tiempo comienza a aceptar que el el formato no está más en tus manos que el código generado).

Sí, porque incluso en este día y edad, algunos de nosotros estamos codificando en terminales (bueno, en su mayoría emuladores de terminal), donde la pantalla solo puede mostrar 80 caracteres. Entonces, al menos para la codificación que hago, realmente aprecio la regla de 80 caracteres.

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

Pero en serio, los problemas que la gente ha planteado en sus respuestas son bastante legítimos. Sin embargo, el cartel original no discutía contra un límite, simplemente que 80 columnas son muy pocas.

El problema de enviar fragmentos de código por correo electrónico tiene algún mérito. Pero teniendo en cuenta las cosas malvadas que la mayoría de los clientes de correo electrónico hacen al texto preformateado, creo que el ajuste de línea es solo uno de sus problemas.

En cuanto a la impresión, generalmente encuentro que las líneas de 100 caracteres encajarán muy cómodamente en una página impresa.

Sigo pensando que el límite no está limitado en la parte visual. Claro, los monitores y las resoluciones son lo suficientemente grandes como para mostrar aún más personajes en una línea hoy en día, pero ¿aumenta la legibilidad?

Si el límite se aplica realmente también es una buena razón para volver a pensar el código y no para poner todo en una línea. Es lo mismo con la sangría: si necesita muchos niveles, debe volver a pensar su código.

Tengo dos monitores de 20 "1600x1200 y me atengo a 80 columnas porque me permite mostrar varias ventanas del editor de texto una al lado de la otra. Usando la fuente ''6x13'' (la fuente tradicional xterm) 80 columnas ocupan 480 píxeles más la barra de desplazamiento y bordes de ventana. Esto permite tener tres ventanas de este tipo en un monitor de 1600x1200. En Windows, la fuente Lucida Console no hará esto (el tamaño mínimo utilizable es de 7 píxeles de ancho) pero un monitor de 1280x1024 mostrará dos columnas y un monitor de 1920x1200, como un HP LP2465 , mostrará 3. También dejará un poco de espacio lateral para los diversos exploradores, propiedades y otras ventanas de Visual Studio.

Además, las líneas de texto muy largas son difíciles de leer. Para texto, el óptimo es de 66 caracteres. Existe un punto en el que los identificadores excesivamente largos comienzan a ser contraproducentes porque dificultan la configuración coherente del código. Una buena disposición e indentación proporciona pistas visuales sobre la estructura del código y algunos lenguajes (Python viene a la mente) usan indentaciones explícitamente para esto.

Sin embargo, las bibliotecas de clases estándar para Java y .Net tienden a tener una preponderancia de identificadores muy largos, por lo que no se puede garantizar necesariamente que se pueda hacer. En este caso, diseñar código con saltos de línea aún ayuda a hacer que la estructura sea explícita.

Tenga en cuenta que puede obtener versiones de Windows de fuentes ''6x13'' Here .

Use fuentes proporcionales.

Lo digo en serio. Normalmente puedo obtener la equivalencia de 100-120 caracteres en una línea sin sacrificar la legibilidad o la capacidad de impresión. De hecho, es aún más fácil de leer con una buena fuente (por ejemplo, Verdana) y coloreado de sintaxis. Parece un poco extraño por unos días, pero te acostumbras rápidamente.

Usted no es la única persona que va a mantener su código.

La siguiente persona que lo haga podría tener una pantalla de 17 "o podría necesitar fuentes grandes para leer el texto. El límite tiene que estar en algún lugar y 80 caracteres es la convención debido a las limitaciones previas de la pantalla. ¿Puede pensar en algún estándar nuevo (120) y ¿Por qué es una buena idea usar ese otro entonces "eso es lo que cabe en mi monitor en la fuente Xpt?"

Recuerde, siempre hay excepciones para cada regla, por lo que tiene una línea o bloque de código en particular que tiene sentido para ser más de 80 caracteres y luego ser un rebelde.

Pero tómate el tiempo primero para pensar "¿es realmente tan malo este código que no puede vivir con 80 caracteres?"

Utilizo la ventaja de las pantallas más grandes para tener varias piezas de código al lado de cada uno.

No recibirás ninguna munición de mi parte. De hecho, odiaría ver que haya cambiado, ya que en situaciones de emergencia todavía veo casos excepcionales en los que necesito cambiar el código de una consola de texto.

Ya hay muchas buenas respuestas a esto, pero vale la pena mencionar que en su IDE puede tener una lista de archivos a la izquierda y una lista de funciones a la derecha (o cualquier otra configuración).

Tu código es solo una parte del entorno.