Question

J'aimerais vraiment voir un IDE de polices proportionnelles, même si je dois le construire moi-même (peut-être comme une extension de Visual Studio).Ce que je veux dire essentiellement, c'est l'édition de code dans le style MS Word qui ressemble en quelque sorte au style typographique de Le livre du langage de programmation C++.

Je souhaite définir des taquets de tabulation pour mes retraits et aligner les signatures de fonction et les lignes d'instructions d'affectation, qui pourraient être spécifiées en points au lieu de positions de caractères fixes.Je voudrais aussi le gras et l'italique.Différentes tailles de police et même des feuilles de style seraient cool.

Quelqu'un a-t-il vu quelque chose comme ça ou connaît la meilleure façon de commencer à en construire un ?

Était-ce utile?

La solution

J'aimerais toujours voir un éditeur ou un IDE populaire implémenter butées élastiques.

Autres conseils

Penser avec style suggère d'utiliser votre logiciel de manipulation de texte préféré comme Word ou Writer.Créez votre code de programme en XML riche et extrayez les sections pertinentes pour le compilateur avec XSLT.Le logiciel « Office » fournira toutes les fonctionnalités avancées de manipulation et de formatage de texte.

Je m'attendais à ce que vous soyez rétrogradé et retenu pour cette suggestion, mais l'idée a un réel sens.

Le principal avantage de l'exigence traditionnelle de police « non proportionnelle » dans les éditeurs de code est de faciliter le formatage du code.

Mais avec tout le formatage automatique interactif présent dans les IDE modernes, il est vraiment possible qu'une police proportionnelle améliore la lisibilité du code (plutôt que de l'entraver, comme s'y attendraient, je suis sûr, de nombreux puristes).

Un personnage appelé Vert Roedy (célèbre pour son 'comment écrire du code non maintenable' articles) a écrit sur un éditeur/langage théorique, basé sur Java et appelé Bali.Il n'incluait pas exactement les polices non proportionnelles, mais il incluait l'idée d'avoir des tailles de police non uniformes.

Aussi, ce court Article de Joel Spolsky publie une solution, des taquets de tabulation élastiques (comme mentionné par un autre commentateur) qui aideraient à prendre en charge les polices non proportionnelles (et de taille variable).

@Thomas Owens

Je ne trouve pas le code ainsi formaté plus facile à lire.

Ce n'est pas grave, c'est juste une préférence personnelle et nous pouvons être en désaccord.Formatez-le de la manière qui vous semble la meilleure et je le respecterai.Je me demande fréquemment «comment dois-je formater ceci ou cette chose? Ma réponse est toujours de le formater pour améliorer la lisibilité, ce que j'avoue peut être subjectif.

Concernant votre exemple, j'aime juste avoir cette colonne bien alignée sur le côté droit, c'est une sorte d'"index" rapide dans le code de gauche.Cela dit, j'éviterais probablement de commenter chaque ligne de cette façon, car le code lui-même ne devrait pas nécessiter autant d'explications.Et si c'est le cas, j'ai tendance à écrire un paragraphe au-dessus du code.

Mais considérons cet exemple tiré de l’affiche originale.Il est plus facile de repérer les commentaires dans le second à mon avis.

for (size-type i = 0; i<v.size(); i++) { // rehash:
    size-type ii = has(v[i].key)%b.size9); // hash
    v[i].next = b[ii]; // link
    b[ii] = &v[i];
}

for (size-type i = 0; i<v.size(); i++) {     // rehash:
    size-type ii = has(v[i].key)%b.size9);   // hash
    v[i].next = b[ii];                       // link
    b[ii] = &v[i];
}

@Thomas Owens

Mais les gens alignent-ils vraiment les commentaires comme ça?...Je n'essaye jamais de faire des déclarations ou des commentaires ou quoi que ce soit, et le seul endroit que j'ai jamais vu dans les manuels.

Oui, les gens alignent les commentaires, les déclarations et toutes sortes de choses.Un code toujours bien formaté est plus facile à lire et un code plus facile à lire est plus facile à maintenir.

Je me demande pourquoi personne ne répond réellement à votre question et pourquoi la réponse acceptée n'a vraiment rien à voir avec votre question.Mais peu importe...

un IDE de polices proportionnelles

Dans Eclipse, vous pouvez choisir n’importe quelle police sur votre système.

définir des tabulations pour mes retraits

Dans Eclipse, vous pouvez configurer l'indentation automatique, notamment en la définissant sur "onglets uniquement".

aligner les signatures de fonction et les lignes d'instructions d'affectation

Dans Eclipse, l'indentation automatique fait cela.

qui pourrait être spécifié en points au lieu de positions de caractères fixes.

Désolé, je ne pense pas qu'Eclipse puisse vous aider.Mais c'est open source.;-)

gras et italique

Eclipse a ça.

Différentes tailles de police et même des feuilles de style seraient cool

Je pense qu'Eclipse n'utilise qu'une seule police et une seule taille de police pour chaque type de fichier (par exemple le fichier source Java), mais vous pouvez avoir différentes "feuilles de style" pour différents types de fichiers.

La dernière fois que j'ai regardé Eclipse (il y a quelque temps maintenant !), il vous permettait de choisir n'importe quelle police installée dans laquelle travailler.Je ne suis pas sûr qu'il prenne en charge la notion d'indentation à l'aide de taquets de tabulation.

Ça avait l'air sympa, mais le code était définitivement plus difficile à lire...

Soeren :C'est plutôt sympa, OMI.Mais est-ce que les gens alignent vraiment les commentaires de cette façon ?Pour mes commentaires de fin de ligne, j'utilise toujours un seul espace puis // ou /* ou équivalent, selon la langue que j'utilise.Je n'essaie jamais d'aligner des déclarations, des commentaires ou quoi que ce soit, et le seul endroit que j'ai jamais vu, c'est dans les manuels scolaires.

@Brian Ensink :Je ne trouve pas le code ainsi formaté plus facile à lire.

int var1 = 1 //Comment
int longerVar = 2 //Comment
int anotherVar = 4 //Command

contre

int var2       = 1 //Comment
int longerVar  = 2 //Comment
int anotherVar = 4 //Comment

Personnellement, je trouve les premières lignes plus faciles à lire que les secondes.

La partie indentation de votre question est réalisée aujourd'hui dans un produit réel, même si peut-être à un niveau d'automatisation encore plus élevé que vous ne l'imaginiez, le produit que je mentionne est un IDE XSLT, mais les mêmes principes de formatage fonctionneraient avec la plupart (mais pas toutes) les syntaxes de code conventionnelles.

Il faut vraiment voir cela dans vidéo pour avoir une idée de tout cela (désolé pour le retour en arrière de la musique).Il existe également un produit dérivé d'un éditeur XML léger, XMLQuire, qui sert de démonstrateur technologique.

La capture d'écran ci-dessous montre du XML formaté avec des règles de formatage assez complexes dans cet IDE XSLT, où toute l'indentation est effectuée à la manière d'un traitement de texte, en utilisant la marge de gauche - et non des caractères d'espace ou de tabulation.

enter image description here

Pour souligner ce concept de formatage, tous les caractères ont été mis en surbrillance pour indiquer où s'étend la marge gauche afin de conserver l'indentation.J'utilise le terme Formatage virtuel pour décrire cela - ce n'est pas comme des taquets de tabulation élastiques, car il n'y a tout simplement pas de tabulations, juste des informations de marge qui font partie du formatage du « paragraphe » (les codes RTF sont utilisés ici).L'analyseur reformate continuellement, au même moment que la coloration syntaxique.

Une police proportionnelle n'a pas été utilisée ici, mais elle aurait pu l'être assez facilement - car l'indentation est définie dans TWIPS.L'expérience d'édition est assez convaincante car, lorsque vous refactorisez le code (XML dans ce cas), peut-être par glisser-déposer, ou en allongeant la longueur d'une valeur d'attribut, l'indentation se redistribue pour s'adapter - il n'y a pas de tabulation. ou le bouton « reformater » sur lequel appuyer.

L'indentation est donc là, mais le travail sur les polices est un problème plus complexe.J'ai expérimenté cela, mais j'ai découvert que si les polices sont resélectionnées au fur et à mesure que vous tapez, le décalage horizontal du code est trop gênant - il faudrait probablement une commande « formater les polices » lancée par l'utilisateur.Le produit intègre également la technologie Ink/Handwriting pour annoter le code, mais je n'ai pas encore exploité cela dans la version live.

Les gens se plaignent tous du fait que les commentaires ne correspondent pas.

Il me semble qu'il existe une solution très simple :Définissez l'espace unité comme le caractère le plus large de la police.Maintenant, espacez proportionnellement tous les caractères sauf l’espace.l'espace prend autant de place pour aligner le caractère suivant là où il se trouverait si tous les caractères précédents de la ligne étaient les plus larges de la police.

c'est à dire:

iii_space_Foo

xxxx_space_Foo

alignerait le "Foo", l'espace après le "i" étant beaucoup plus large qu'après le "x".

Alors appelez cela des espaces élastiques.plutôt que des tabulations.

Si vous êtes un éditeur intelligent, traitez les commentaires de manière spéciale, mais ce n'est que de la sauce

Permettez-moi de rappeler les arguments concernant l'utilisation du mot-clé 'var' en C#.Les gens détestaient cela et pensaient que cela rendrait le code moins clair.Par exemple, vous ne pouvez pas connaître le type de quelque chose comme :

var x = GetResults("Main");
foreach(var y in x)
{
   WriteResult(x);
}

Leur argument était que vous ne pouviez pas voir si x était un tableau, une liste ou tout autre IEnumerable.Ou quel était le type de y.À mon avis, le manque de clarté ne vient pas de l'utilisation de var, mais du choix de noms de variables peu clairs.Pourquoi ne pas simplement taper :

var electionResults = GetRegionalElactionResults("Main");
foreach(var result in electionResults)
{
   Write(result); // you can see what you're writing!!
}

"Mais vous ne pouvez toujours pas voir le type de résults électoraux!" - est-ce que c'est vraiment important?Si vous souhaitez modifier le type de retour de GetRegionalElectionResults, vous pouvez le faire.N’importe quel IEnumerable fera l’affaire.

Avance rapide jusqu’à maintenant.Les gens veulent aligner les commentaires sur un code similaire :

int var2       =  1; //The number of days since startup, including the first
int longerVar  =  2; //The number of free days per week
int anotherVar = 38; //The number of working hours per week

Donc, sans le commentaire, tout n'est pas clair.Et si vous n'alignez pas les valeurs, vous ne pouvez pas les séparer des variables.Mais le fais-tu?Qu'en est-il de ça (ignorez les puces s'il vous plaît)

  • int joursSinceStartup = 1 ;// y compris le premier
  • int freeDaysPerWeek = 2;
  • int workingHoursPerWeek = 38;

Si vous avez besoin d'un commentaire sur CHAQUE LIGNE, vous faites quelque chose de mal."Mais vous devez encore aligner les VALEURS" - n'est-ce pas ?qu'est-ce que 38 a à voir avec 2 ?

En C#, la plupart des blocs de code peuvent facilement être alignés en utilisant uniquement des tabulations (ou généralement des multiples de quatre espaces) :

  • var régionsAvecAugmentation =
    • à partir du résultat dans GetRegionalElectionResults()
    • où résultat.TotalCount > résultat > PrécédentTotalCount &&
      • result.PreviousTotalCount > 0 // juste de nouvelles régions
    • sélectionnez le résultat.Région ;
  • foreach (var région dans régionsWithIncrease)
  • {
    • Écrire (région);
  • }

Vous ne devriez jamais utiliser de commentaires ligne à ligne et vous devriez rarement avoir besoin d’aligner les choses verticalement.Rarement, pas jamais.Je comprends donc si certains d’entre vous préfèrent une police à espacement fixe.Je préfère la lisibilité de la police Noto Sans ou Source Sans Pro.Ces polices sont disponibles gratuitement sur Google, et ressemblent à Calibri, mais sont conçues pour la programmation et possèdent donc toutes les caractéristiques nécessaires :

  • Grand :;., pour que vous puissiez clairement voir la différence
  • 0Oo clairement distinct et Il|

Le problème majeur des polices proportionnelles est qu'elles détruisent l'alignement vertical du code et c'est une perte assez importante lorsqu'il s'agit d'écrire du code.

L'alignement vertical permet de manipuler des blocs de code rectangulaires qui s'étendent sur plusieurs lignes en permettant d'effectuer facilement des opérations de bloc telles que couper, copier, coller, supprimer et mettre en retrait, annuler le retrait, etc.

À titre d'exemple, considérons cet extrait de code :

a1 = a111;
B2 = aaaa;
c3 = AAAA;
w4 = wwWW;
W4 = WWWW;

Dans une police à espacement fixe, le = et le ; tous font la queue.

Maintenant, si ce texte est inséré dans Mot et afficher à l'aide d'un police proportionnelle le texte se transforme effectivement en ceci :

NOTE: Espace blanc supplémentaire ajouté pour montrer comment le = et ; ne font plus la queue :

a1 = a1 1 1;
B2  = aaaa;
c3 = A A A A;
w4 = w w W  W;
W4  = W W W  W;

Avec la disparition de l’alignement vertical, ces jolis blocs de code disparaissent effectivement.

Aussi parce qu'il n'est plus garanti que le curseur se déplace verticalement (c'est-à-direle numéro de colonne n'est pas toujours constant d'une ligne à l'autre), cela rend plus difficile l'écriture de scripts de macro jetables conçus pour manipuler des lignes d'apparence similaire.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top