Pourquoi utiliser des polices monospace dans votre IDE?

Question

J'ai vu quelques sujets sur les polices sur SO et il semble qu'une majorité de gens utilisent des polices monospaces pour des tâches de programmation. J'utilise Verdana pour la programmation depuis quelques années et j'aime vraiment la lisibilité améliorée, sans rien manquer de monospace.

Pourquoi utilisez-vous une police monospace?

Ryan · Answer

Dans une police monospace:

Les littéraux de chaîne de longueur égale sont égaux.
Il est plus facile de voir des signes de ponctuation fins comme: () {}
Des personnages similaires sont plus différents: Il 0O vs Il 0O
Vous savez si une ligne se déroulera sur une fenêtre de X caractères ou non. Cela signifie que votre équipe peut normaliser disons 100 lignes de caractères et qu'une ligne ressemblera toujours à une ligne

Dan · Answer

Je n'ai même jamais envisagé de coder dans une police proportionnelle auparavant. Donc, dans l'intérêt de la science, je viens de changer mon éditeur pour l'essayer.

Voici quelques observations après avoir corrigé quelques tickets faciles:

Le code semble extrêmement dense. La plupart de mon code est d'environ 80 colonnes, rarement plus de 100. Une police proportionnelle l'écrase sur une petite bande sur le côté gauche de mon éditeur. Peut-être utile si votre espace d'écran est court, mais il semble inutilement compact.
La "texture" du code est perdue. Il est difficile de dire quel type de structure je regarde - c'est juste une grande dalle de texte qui doit être lue presque caractère par caractère.
Il est très facile de manquer l'opérateur ! Dans if (!foo). (si (! foo), voyez!)
Les caractères de ponctuation sont très mal définis. Beaucoup sont difficiles à distinguer ({}[]() vs {} [] ())
Certains caractères de ponctuation sont beaucoup plus volumineux que d'autres, ce qui implique une emphase là où aucun n'est prévu ($@% Vs $ @%)
Certains caractères sont très étroits et très difficiles à identifier ('"!;:,. Vs '"!;:,.)
Certains chiffres et lettres sont très similaires (0Oo iIl Vs 0Oo iIl)
Je suis extrêmement dépendant de la coloration syntaxique, sans quoi il est presque impossible de faire des choses comme confirmer que les citations sont équilibrées, etc.
L'alignement (en dehors de la simple mise en retrait) est complètement rompu. Vous pouvez trier l'aile en lançant des espaces supplémentaires, mais en raison de la nature proportionnelle des polices, les lignes peuvent ne pas s'aligner exactement - le code semble plus compliqué.
Les expressions régulières sont .. intéressantes!

Il y a sont quelques points positifs, cependant. Certes, je ne l'utilise que depuis un petit moment, mais il y a certainement certains aspects qui fonctionnent un peu mieux avec les polices proportionnelles:

les "mots" sont plus faciles à lire - des fautes d'orthographe (par exemple, une orthographe incorrecte d'une variable) vous sautent aux yeux.
Je préfère utiliser des noms de variables plus longs et plus descriptifs (peut-être parce qu'ils scannent mieux, peut-être parce que la taille horizontale du texte est compressée)
Il semble légèrement plus facile de - lire coder comme ça. Il est plus facile pour mon cerveau de "tokeniser" chaque mot et de comprendre sa signification. Bien que les caractères de ponctuation soient plus difficiles à lire, c'est toujours difficile - mais cela changera peut-être avec un peu de temps pour s'y habituer

Je mettrai à jour cette réponse à nouveau demain (en supposant que je puisse passer une journée entière comme ça!)

DGentry · Answer

J'aime aligner les conditionnelles liées, pour essayer de rendre plus évident qu'elles sont groupées. Par exemple:

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

Les polices à largeur variable rendent cela plus difficile.

bwerks · Answer

Une chose que je continue de voir ici est la discussion sur "aligner le code" et l'indentation. Je voudrais souligner les choses suivantes:

huit espaces seront toujours deux fois plus longs que quatre espaces dans n'importe quelle police.
deux onglets seront toujours deux fois plus longs qu'un onglet dans n'importe quelle police.
tout identifiant sur une ligne aura toujours la même largeur sur la ligne suivante ... dans n'importe quelle police!
bien sûr, si vos coéquipiers utilisent le monospace et que vous ne l'êtes pas, cela aura l'air différent ... mais vous devriez normaliser quelque chose - quoi que ce soit - et si c'est vrai, alors ça ressemblera à tout le monde. ..dans TOUTE police! Pour rire, vous pouvez également essayer de garder tout le monde sur monospace et de donner à la moitié d'entre eux des moniteurs à écran large ... voyez comment cela se passe.
Si vous faites quoi que ce soit qui repose sur l'alignement de code basé sur la position en colonnes de ces caractères à l'écran, et non sur la portée des identifiants que vous utilisez, je pose que ce que vous faites est un hack. Les identifiants ne doivent jamais être limités à un certain nombre de caractères au détriment de la qualité de leurs noms. Mis à part cela ... vous n'êtes pas encore en train de dessiner ASCII boîtes avec des astérisques pour les commentaires dans votre code, êtes-vous?

Donc, en rassemblant tout cela, si vous commencez chaque ligne au même endroit, et que l'espacement constant est de la même largeur, et que les identificateurs ne changent pas spontanément de largeur sur chaque ligne, alors votre code s'alignera! ... jusqu'à ce que quelque chose soit différent.

par exemple:

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 non! mal aligné!
identifier.Method (). Sumthing.YouGetThePoint; //...mais qui s'en soucie? ce sont des propriétés différentes!

Le seul point que je concède est que les caractères non alphanumériques ne sont généralement pas très larges; ceux-ci incluent) (] [} {,: | "; ',`! et. Cela pourrait cependant être corrigé dans un éditeur de polices ... simplement en les élargissant. Ce n'est pas un problème inhérent à la non-monospace; il n'y a tout simplement pas il n'y a pas eu beaucoup de demande pour cela, et donc cela n'a pas encore été fait.

En résumé, les préférences personnelles sont bonnes, mais je pense qu'il n'y a pas de raison pratique de préférer le monospace au non-monospace. Vous aimez son apparence? Bien sûr, monospace. Vous voulez que plus de choses tiennent sur votre écran? Passez en mono. Mais la façon dont les gens traitent le non-espace comme l'hérésie est un peu exagérée.

Konrad Rudolph · Answer

Je suis devenu curieux par ce fil parce que de nombreux arguments pour les polices à espacement fixe peuvent vraiment être réfutés facilement avec quelques ajustements. J'ai donc changé mon IDE en Calibri (car il a un joli visage rond et est optimisé pour la lisibilité sur les écrans pour l'interface utilisateur - parfait). Maintenant, je dois évidemment utiliser des tabulations à la place des espaces pour l'indentation ( en ignorant tous les problèmes) et la largeur de 4 espaces ne suffit clairement pas, je suis donc passé à 10.

Ça a l'air bien maintenant. Cependant, il y a quelques problèmes évidents que j'ai pu repérer. D'autres pourraient apparaître plus tard, après avoir testé ces paramètres pendant un certain temps.

Comme déjà mentionné, certains caractères (en particulier les parenthèses, les points-virgules) semblent beaucoup trop minces. Je veux cela dans un texte continu mais pas dans un code source. Je pense que ce sera le plus gros problème.
Les symboles ne s'alignent pas bien. Par exemple, considérons le code C # suivant:
```
var expr = x => x + 1; 
```
La flèche (=>) ressemble à une unité dans n'importe quelle police à espacement fixe. Il ressemble à deux caractères adjacents dans d'autres polices. Il en va de même pour les opérateurs comme >> etc.
Les espaces sont minuscules. J'espace vigoureusement mes codes sources pour améliorer la lisibilité. Cela ne sert à rien lors du passage à une police proportionnelle. Si je pouvais contrôler la largeur des espaces, cela aiderait certainement.
L'indentation contextuelle est complètement rompue: dans certains contextes, il ne suffit pas d'indenter un nombre fixe d'onglets. Prenez des expressions LINQ qui pourraient être mises en retrait de la manière suivante:
```
var r = from c in "This, apparently, is a test!" where !char.IsPunctuation(c) select char.ToUpper(c); 
```
Vous ne pouvez tout simplement pas le faire avec une police proportionnelle.

Dans l'ensemble, les personnages sont trop étroits. Encore une fois, un espacement des lettres supplémentaire pourrait aider et c'est certainement nécessaire dans le cas de la ponctuation. Cependant, j'ai le sentiment que tous ces ajustements pour rendre les polices proportionnelles plus lisibles imiteraient naturellement les polices à espacement normal. C'est certainement vrai pour tous les points mentionnés jusqu'à présent.

James Curran · Answer

J'utilise Comic Sans MS, qui semble assez raisonnable en tant que petites tailles de points (il ne commence à regarder "jokey" qu'aux tailles de titre). C'est facile pour les yeux, mais gardez toujours le texte suffisamment petit pour avoir une quantité raisonnable de code visible dans la fenêtre de texte, avec plusieurs panneaux ancrés de VS ouverts.

Vous pouvez désactiver le panneau Explorateur de solutions et disposer de 100 colonnes de texte lisibles sans défilement horizontal. De plus, je peux avoir le panneau DXCore Documentor (affichant les XMLDOC formatés) suffisamment ouvert pour lire tout en étant capable de voir suffisamment de texte pour documenter les XMLdocs.

Tom Robinson · Answer

Si vous travaillez en équipe, les polices mono-espacées garantissent que le code est clair et correctement mis en page pour tout le monde, quelle que soit la police mono-espacé qu'ils préfèrent utiliser.

Votre code peut vous sembler clair lorsque vous utilisez une police à largeur variable, mais il est peu probable qu'il ait la même apparence si un utilisateur de police à espacement mono l'ouvre.

bruceatk · Answer

Il suffit de quelques heures pour essayer de comprendre pourquoi une recherche ne trouve rien parce que vous avez 2 espaces au lieu de 1 dans votre littéral, pour vous rendre compte que vous devriez utiliser les polices Monospace. Cela m'est arrivé une fois lors de la tentative de correction d'un agent Lotus Notes, lorsque le concepteur n'utilisait pas de police monospace. Ce n'est que lorsque j'ai collé le code dans CodeWright pour l'imprimer qu'il était évident quel était le problème.

SLaks · Answer

Les polices espacées facilitent beaucoup l'alignement du code.

Cela est particulièrement vrai lorsque vous travaillez avec une équipe; tout le monde dans l'équipe peut utiliser des polices différentes, et tant qu'ils sont tous à espacement fixe, tout s'alignera. De même, si une seule personne utilise de nombreux outils de développement différents, tout s'alignera s'ils sont tous à espacement fixe. S'ils n'étaient pas tous à espacement fixe, vous devez vous assurer qu'ils utilisent tous la même police, et si vous développez sur deux plates-formes, cela peut être difficile.

En fait, certains outils de développement ne prennent en charge que les polices à espacement fixe.

Une autre raison est que les polices à espacement fixe ont tendance à avoir des caractères plus distincts. Comparez lIiO0 à lIiO0, et vous verrez ce que je veux dire. Ils facilitent également le comptage des espaces.

spoulson · Answer

Je soupçonne que les polices à espacement fixe étaient la préférence d'un programmeur comme report des jours DOS basés sur du texte.

D'un autre côté, j'ai moi-même essayé Verdana et quelques autres polices proportionnelles recommandées, mais je n'ai pas pu faire face au changement. Mon œil est trop bien entraîné pour le monospace. Les langages chargés de symboles, comme: C/C++, C #, Perl, etc., me semblent trop différents. L'emplacement des symboles rend le code complètement différent.

stephenbayer · Answer

De par la nature du code plutôt que du langage ordinaire, il est plus agréable de l'aligner correctement. De plus, dans l'édition de code, vous souhaitez parfois bloquer la sélection, bloquer la copie et bloquer la pâte. Dans Visual Studio, vous pouvez effectuer la sélection de bloc en utilisant la touche ALT tout en faisant votre sélection de souris. Cela peut être différent dans différents éditeurs, mais j'ai toujours trouvé cette option dans un éditeur très importante dans certains cas, et cela ne fonctionnerait pas très bien, sauf si vous utilisez une police à espacement mono.

John Kraft · Answer

Personnellement, je trouve les polices mono-espacées plus faciles à lire dans les éditeurs de code. Bien sûr, je suis presque aveugle. Cela pourrait faire une différence. J'exécute actuellement la police consolas à 15 points avec un fond sombre avec des lettres à contraste élevé.

jammus · Answer

L'utilisation d'espaces pour l'indentation serait un problème une fois que vous auriez atteint plus d'un niveau.

mipadi · Answer

Principalement à des fins d'alignement (comme lorsque les déclarations de paramètres de fonction s'étendent sur plusieurs lignes et que vous souhaitez les aligner, ou aligner des commentaires, etc.).

Alan Hensel · Answer

Je pense, tout comme la question des caractères de tabulation, le facteur de complication est lorsque quelque chose est mis en retrait à des fins d'alignement, et que quelqu'un d'autre a des préférences différentes. Les choses sont mal alignées.