tarjetas - ¿Por qué usar fuentes monoespaciales en su IDE?

fuentes windows 10

Question

He visto un par de temas de fuentes en SO y parece que la mayoría de las personas usa fuentes monoespaciales para tareas de programación. He estado usando Verdana para programar durante un par de años y realmente me gusta la legibilidad mejorada, sin perderme nada relacionado con el monoespacio.

¿Por qué usas una fuente monoespaciada?

Answer 1

Creo que, al igual que el tema de los tabuladores, el factor que complica la situación es cuando algo se sangra para fines de alineación, y otra persona tiene preferencias diferentes. Las cosas se desalinean.

Answer 2

El uso de espacios para sangría sería un problema una vez que hayas alcanzado más de un nivel.

Answer 3

En una fuente monoespacial:

• Los literales de cadena de igual longitud se ven iguales.
• Es más fácil ver signos de puntuación delgados como: () {}
• Caracteres similares parecen más diferentes: Il 0O vs Il 0O
• Usted sabe si una línea se ajustará o no a una ventana de X caracteres de ancho. Esto significa que su equipo puede estandarizar, por ejemplo, 100 líneas de caracteres y una línea siempre se verá como una línea

Answer 4

Las fuentes monoespaciadas hacen que sea mucho más fácil alinear el código.

Esto es especialmente cierto cuando se trabaja con un equipo; todos en el equipo pueden usar diferentes tipos de letra, y mientras estén todos monoespaciados, todo se alineará. Del mismo modo, si una sola persona utiliza muchas herramientas de desarrollo diferentes, todo se alineará si están todos monoespaciados. Si no estuviesen todos monoespaciados, tendrías que asegurarte de que todos usan la misma fuente, y si estás desarrollando en dos plataformas, eso puede ser difícil.

De hecho, algunas herramientas de desarrollo solo admiten fuentes monoespaciadas.

Otra razón es que las fuentes monoespaciadas tienden a tener caracteres más distintos. Compare lIiO0 con lIiO0 , y verá lo que quiero decir. También hacen que sea mucho más fácil contar espacios en blanco.

Answer 5

Me gusta alinear condicionales relacionados, para intentar que sea más obvio que están agrupados. Por ejemplo:

if ((var1 == FOO) && ((var2 == BAR) ||
                      (var2 == FOOBAR)))

Las fuentes de ancho variable lo hacen más difícil.

Answer 6

Me he vuelto curioso por este hilo porque muchos argumentos para las fuentes monoespaciadas realmente se pueden refutar fácilmente con algunos ajustes. Así que cambié mi IDE a Calibri (porque tiene una cara bonita y redonda y está optimizado para la legibilidad en pantallas para UI, perfecto). Ahora, obviamente, tengo que usar pestañas en lugar de espacios para la sangría (ignorando todos los problemas) y el ancho de 4 espacios claramente no es suficiente, así que cambié a 10.

Se ve bastante bien ahora. Sin embargo, hay algunos problemas obvios que pude detectar. Más podría salir a la superficie más tarde, después de haber probado esta configuración por un tiempo.

• Como ya se mencionó, algunos personajes (especialmente entre paréntesis, punto y coma) parecen demasiado delgados. Quiero esto en un texto continuo pero no en un código fuente. Creo que este será el mayor problema.

• Los símbolos no se alinean bien. Como ejemplo, considere el siguiente código de C #:

  var expr = x => x + 1;

  La flecha ( => ) se ve como una unidad en cualquier fuente de monoespacio. Se ve como dos caracteres adyacentes en otras fuentes. Lo mismo es cierto para operadores como >> etc.

• Los espacios se ven diminutos. Espacio mis códigos fuente enérgicamente para mejorar la legibilidad. Esto no sirve para nada cuando se cambia a una fuente proporcional. Si pudiera controlar el ancho de los espacios, esto definitivamente ayudaría.

• La sangría sensible al contexto está completamente rota: en algunos contextos, no es suficiente con la indentación de un número fijo de pestañas. Tome expresiones LINQ que pueden sangrarse de la siguiente manera:

  var r = from c in "This, apparently, is a test!"
          where !char.IsPunctuation(c)
          select char.ToUpper(c);

  Simplemente no puedes hacer esto con una fuente proporcional.

En general, los personajes son demasiado estrechos. Una vez más, un espaciado de letras adicional podría ayudar y, definitivamente, es necesario en el caso de la puntuacion. Sin embargo, tengo la sensación de que todo este ajuste para que las fuentes proporcionales sean más legibles simplemente emularía las fuentes monoespaciadas de forma natural. Es cierto para todos los puntos mencionados hasta ahora.

Answer 7

Nunca antes había considerado codificar en una fuente proporcional. Entonces, en interés de la ciencia, cambié mi editor para probarlo.

Aquí hay algunas observaciones después de arreglar un par de entradas fáciles:

• El código parece extremadamente denso. La mayor parte de mi código es de alrededor de 80 columnas, rara vez más de 100. Las fuentes proporcionales lo reducen a una pequeña tira en el lado izquierdo de mi editor. Tal vez sea útil si tiene poco espacio en la pantalla, pero parece innecesariamente compacto.
• La ''textura'' del código se pierde. Es difícil decir qué tipo de estructura estoy mirando, es solo una gran capa de texto que debe leerse casi carácter por carácter.
• ¡Es muy fácil perderse ! operador en if (!foo) . (si (! foo), ¡mira!)
• Los caracteres de puntuación están muy mal definidos. Muchos son difíciles de distinguir ( {}[]() vs {} [] ())
• Algunos caracteres de puntuación son mucho más grandes que otros, infiriendo énfasis donde no se pretende ninguno ( $@% vs $ @%)
• Algunos caracteres son muy estrechos y muy difíciles de identificar ( ''"!;:,. Vs '''' '''' '''' '''' '''' '''' '''' '''' '''' '''' '''' '''' '':!
• Algunos números y letras son muy similares ( 0Oo iIl vs 0Oo iIl)
• Depende mucho del resaltado de sintaxis, sin él es casi imposible hacer cosas como confirmar presupuestos, etc.
• La alineación (aparte de la sangría simple) está completamente rota. Puede ordenarlo alejando espacios adicionales, pero debido a la naturaleza proporcional de las fuentes, las líneas pueden no alinearse exactamente: el código parece más desordenado .
• Las expresiones regulares son ... interesantes!

Sin embargo, hay algunos puntos positivos. Es cierto que solo he estado usándolo por un tiempo, pero ciertamente hay algunos aspectos que funcionan un poco mejor con fuentes proporcionales:

• Las "palabras" son más fáciles de leer: los errores ortográficos (por ejemplo, deletrear incorrectamente una variable) saltan hacia ti.
• Me siento mejor sobre el uso de nombres de variables más largos y descriptivos (tal vez porque escanean mejor, tal vez porque el tamaño horizontal del texto está comprimido)
• Parece un poco más fácil leer código como este. Es más fácil para mi cerebro ''juntar'' cada palabra y entender su significado. Aunque debido a que los caracteres de puntuación son más difíciles de leer, todavía es difícil, pero tal vez eso cambie dado un tiempo para acostumbrarse.

Volveré a actualizar esta respuesta mañana (¡suponiendo que pueda superar un día como este!)

Answer 8

Personalmente encuentro que las fuentes monoespaciadas son más fáciles de leer en los editores de códigos. Por supuesto, estoy casi ciego. Eso podría hacer una diferencia. Actualmente ejecuto la fuente de consolas en 15 puntos con un fondo oscuro con letras de alto contraste.

Answer 9

Por la naturaleza del código en lugar del lenguaje habitual, es mejor tenerlo alineado correctamente. Además, en la edición de código, a veces se desea bloquear seleccionar, bloquear copiar y bloquear pegar. En Visual Studio, puede hacer la selección de bloque utilizando la tecla ALT mientras hace la selección del mouse. Puede ser diferente en diferentes editores, pero siempre he encontrado esa opción en un editor muy importante en algunos casos, y no funcionaría muy bien, a menos que esté usando una fuente de monoespaciado.

Answer 10

Principalmente para fines de alineación (como cuando las declaraciones de parámetros de función abarcan varias líneas y desea alinearlas, alinear comentarios, etc.).

Answer 11

Si trabajas en equipo, las fuentes monoespaciadas aseguran que el código sea claro y esté correctamente distribuido para todos, independientemente de la fuente monoespaciada que prefieran utilizar.

Su código puede parecer claro para usted cuando utilice una fuente de ancho variable, pero es poco probable que tenga el mismo aspecto si lo abre un usuario de fuente de espacio único.

Answer 12

Sospecho que las fuentes monoespaciadas eran las preferencias de un programador como un arrastre de los días de DOS basados ​​en texto.

Por otro lado, yo mismo probé con Verdana y algunas otras fuentes proporcionales recomendadas, pero no pude lidiar con el cambio. Mi ojo está muy bien entrenado para el monoespacio. Los idiomas cargados de símbolos, como: C / C ++, C #, Perl, etc., se ven demasiado diferentes para mí. La colocación de símbolos hace que el código se vea completamente diferente.

Answer 13

Todo lo que se necesita son unas pocas horas de intentar descubrir por qué una búsqueda no es encontrar algo porque tienes 2 espacios en lugar de 1 en tu literal, para darte cuenta de que debes usar las fuentes Monospace. Me sucedió esto una vez cuando intenté arreglar un agente de Lotus Notes, cuando el diseñador no estaba usando una fuente monoespaciada. No fue hasta que pegué el código en CodeWright para imprimirlo que era obvio cuál era el problema.

Answer 14

Una cosa que sigo viendo aquí es la discusión de "alinear el código" y la sangría. Me gustaría señalar las siguientes cosas:

• ocho espacios siempre serán dos veces más largos que cuatro espacios en cualquier fuente.
• dos pestañas siempre serán dos veces más largas que una pestaña en cualquier fuente.
• cualquier identificador en una línea siempre tendrá el mismo ancho en la siguiente línea ... ¡en cualquier fuente!
• claro, si tus compañeros de equipo están usando el monoespacio y tú no, se verá diferente ... pero deberías estandarizarte en algo, sea lo que sea, y si eso es cierto, se verá igual para todos. ..en CUALQUIER fuente! Para reírse, también podría tratar de mantener a todos en el espacio mono y dar a la mitad de ellos monitores de pantalla panorámica ... vea cómo va eso.
• Si está haciendo algo que dependa de alinear el código según la posición de columna de esos caracteres en la pantalla, y no el alcance de los identificadores que está utilizando, supongo que lo que está haciendo es un truco. Los identificadores nunca deben estar limitados a un cierto número de caracteres a costa de la calidad de sus nombres. Aparte de eso ... no estás dibujando cuadros ASCII con asteriscos para comentarios en tu código, ¿o sí?

Así que al unir todo esto, si comienzas cada línea en el mismo lugar, y el espaciado constante es del mismo ancho, y los identificadores no cambian el ancho de forma espontánea en cada línea, ¡entonces tu código realmente se alineará! ... hasta que algo sea diferente.

por ejemplo:

identifier.Method().Property.ToString();
identifier.Method().OtherGuy.ToString(); //how lined up and pretty!
identifier.Method().Sumthing.YouGetThePoint;

• identifier.Method (). Property.ToString ();
• identifier.Method (). OtherGuy.ToString (); //¡Oh no! desalineado!
• identifier.Method (). Sumthing.YouGetThePoint; //...¿pero a quién le importa? son propiedades diferentes!

El único punto que concederé es que los caracteres no alfanuméricos generalmente no son muy amplios; estos incluyen) (] [} {,: | "; '',`! y. Sin embargo, esto podría arreglarse en un editor de fuentes ... simplemente haciéndolos más amplios. No es un problema inherente con el no-monoespacio; Ha habido mucha demanda, y aún no se ha hecho.

En resumen, la preferencia personal está bien, pero creo que hay pocas razones prácticas para preferir el monoespacio sobre el no monoespacio. Te gusta el aspecto? Claro, haz el monoespacio. ¿Quieres más cosas para que quepan en tu pantalla? No ser mono. Pero la forma en que las personas tratan el no-monoespacio como una herejía es un poco exagerado.

Answer 15

Uso Comic Sans MS, que se ve bastante razonable como pequeños tamaños de punto (solo comienza a verse "jokey" en los tamaños de titulares). Es fácil para los ojos, y aún así mantener el texto lo suficientemente pequeño como para tener una cantidad razonable de código visible en la ventana de texto, con varios paneles acoplados de VS abiertos.

Puede tener el panel Explorador de soluciones desactivado, y aún así tener 100 columnas de texto legibles sin desplazamiento horizontal. Además, puedo hacer que el panel DXCore Documentor (que muestra los XMLDOC formateados) se abra lo suficiente para poder leer mientras todavía se puede ver suficiente texto para doc el XMLdocs.