Je lisais Code complet et dans le chapitre sur la mise en page et le style, il prédisait que les éditeurs de code utiliseraient une sorte de formatage de texte enrichi. Cela signifie, au lieu de code ressemblant à ceci

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

cela pourrait ressembler à ceci:

Procédure ResolveCollisions

Effectue une résolution de collision a posteriori grâce à un algorithme de partitionnement spatial

Paramètres

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

Variables locales

• Collider : Sprite
• Collidee : Sprite
• Collision : SpriteCollision

    DoStuff();

J'ai vu la coloration et la mise en évidence de la syntaxe et même la coloration des parenthèses, mais rien qui ressemble à ceci dans le code réel. Je me demandais si ce genre de chose avait réellement existé, ou peut-être s'il avait été décidé qu'il n'avait pas suffisamment d'avantages ou que c'était une très mauvaise idée.

Avez-vous déjà vu du code au format riche comme celui-ci auparavant, ou savez-vous si l'idée a été envisagée et finalement rejetée?

Il n'y a aucune raison technique que vous ne pouviez pas. Si les éditeurs de texte peuvent mettre en évidence la syntaxe, ils pourraient tout aussi facilement changer d'autres aspects de l'affichage pour mettre en évidence le code.

Cependant, c'est une chose que ce qui est tapé change de couleur pendant que l'éditeur détermine ce que vous tapez. Le fait que le texte change soudainement de taille et saute pendant que vous tapez serait vraiment désagréable.

Cependant, pour un affichage de code «statique», vous pouvez facilement embellir le code source. Par exemple, prenez n'importe quel convertisseur source-> html à moitié décent, et ajoutez les tailles de police et les styles que vous aimez aux feuilles de style, et vous aurez un code formaté riche.

Raison simple: indépendance éditeur / outil.

Une fois que vous avez créé un code «riche» - il sera lié à l'éditeur que vous avez utilisé - ou à ceux qui peuvent comprendre le code riche. Tous les autres éditeurs qui ne peuvent pas gérer la richesse afficheront du charabia.

Dans la même veine, le code riche ne fonctionnerait pas bien avec les outils de diff. Par exemple, si vous venez de modifier une mise en forme, le diff affichera une différence, mais ce n'est même pas une différence qui vous préoccupe le moins.

Et qu'en est-il du contrôle de version? Comment lui diriez-vous d'ignorer toutes les modifications de mise en forme et de ne voir les fichiers modifiés que lorsqu'il y a de «vrais» changements.

Enfin, je suppose que l'intérêt du code riche est la lisibilité - et pour cela, je pense que de meilleurs (et plus) commentaires, noms d'identificateurs logiques et indentation cohérente suffiront.

En substance, le texte de programmation est mieux géré comme un texte brut - ce que vous voyez est ce que la réalité. ( ce qui est également conforme à l'idée pythonique d'explicite mieux qu'implicite )

Peut-être que le code richement formaté n'a pas fait son chemin parce que ce n'est pas une bonne idée. Personnellement, je n'aime pas ce que je vois dans l'exemple que vous avez fourni. J'utilise la coloration syntaxique et la mise en évidence, mais cette mise en forme est trop travaillée et elle s'écarte trop de la façon dont j'ai l'habitude de voir et d'écrire du code.

Pourquoi ça n'existe pas? Il n'y en a pas la demande / le besoin.

Les éditeurs actuels sont en mesure de satisfaire les besoins des programmeurs avec la mise en évidence de la syntaxe et quelques autres options stylistiques mineures. N'est-ce pas déjà du "texte riche"?

Cela existe déjà pour LaTeX en mode AucTeX pour Emacs. Les titres de section sont de plus grande taille, les sous-scripts et les exposants sont redimensionnés de manière appropriée et vous pouvez même avoir de petits aperçus de mathématiques (et éventuellement d'autres environnements comme Algorithmic).

C'est très bien pour LaTeX car le mappage du code vers la sortie est généralement beaucoup plus simple que dans d'autres programmes; Je pense que je ne voudrais pas du tout cela pour des langues plus générales.

Une autre chose qu'Emacs peut faire est de remplacer les symboles comme ->et forallpar →et ∀respectivement dans Haskell. Il y a peu de raisons pour lesquelles ce genre de chose ne peut pas être étendu à la mise en forme comme vous le suggérez, sauf que ce n'est pas du tout nécessaire dans Haskell.

Il y a quelque temps, j'ai posé cette question sur la mise en forme du code, demandant si les programmeurs voudraient que leur code soit mis en forme lors de la frappe.

Ma question ne portait que sur l'indentation de la mise en forme, mais certaines réponses pourraient bien s'appliquer au formatage du code en général. Le sentiment général dans les réponses suggère que les programmeurs sont opposés à perdre le contrôle absolu de la façon dont leur code est représenté.

Mon expérience personnelle a été très différente. Bien que j'utilise normalement des outils accessibles au public, j'ai parfois besoin d'écrire XSLT dans mon propre éditeur sur mesure. Cet éditeur formate le code au fur et à mesure que je tape en mettant en retrait la marge gauche, je n'ai donc aucun problème avec les espaces indésirables (significatifs en XSLT) et permet à mon code de passer à la ligne et de conserver le formatage. Je trouve l'expérience assez naturelle, le style de formatage est contrôlé par le contexte et la position des sauts de ligne seuls (l'expérience est particulièrement gratifiante lors de l'utilisation de périphériques d'entrée tactiles).

Si le XSLT n'est pas bien équilibré, la mise en forme permet en fait de montrer où se situe le problème. Il a fallu un certain temps pour s'adapter au décalage de code horizontalement lors de la frappe, mais ce n'est plus une distraction pour moi. Cependant, j'ai trouvé que les fonctionnalités de formatage qui affectaient l'espacement vertical de mon XSLT rendaient l'éditeur presque inutilisable, donc je les ai désactivées.

Pour revenir à votre question, je pense que la raison pour laquelle le formatage de code riche n'est pas plus courant est simplement qu'il faut beaucoup de temps pour que les perceptions changent dans le monde de la programmation. Son temps viendra, coïncidant peut-être avec le moment où l'édition de code se fait principalement sans clavier.

Aussi dans plus de quelques langages (Haskell, Ruby, Python, Erlang, CoffeeScript quelques autres) l'indentation est importante. Donc, si vous changez la taille des polices, il pourrait être très difficile à comprendre.

Surtout sa tradition. Je programme professionnellement depuis près de 20 ans et je pense que cela me rendrait fou. J'écris des livres dans Emacs ou VI avec docbook, donc je ne suis pas un fan de WYSIWIG

CWEB de Knuth fait cela, mais il ne fonctionne que pour C / C ++ et Pascal. - Mais tu devrais y jeter un coup d'œil… c'est assez soigné. Il existe deux programmes: ctangleet cweavequi combinent / séparent les fichiers CWEB en TeX et C respectivement.

Avez-vous déjà vu du code au format riche comme celui-ci auparavant, ou savez-vous si l'idée a été envisagée et finalement rejetée?

Sûr. Xcode prend en charge les styles au-delà de la simple coloration pour une syntaxe différente:

Cela fait longtemps que je ne l'ai pas utilisé, mais je pense que Metrowerks CodeWarrior a également pris en charge le texte stylé, et c'était il y a 10+ ans.

Cependant, vous ne voulez pas aller trop loin avec les styles - tout texte, code source ou autre, peut être plus difficile à lire lorsque les styles varient trop. En particulier, je pense que le mélange des tailles est gênant, et tout ce qui empêche les colonnes de s'aligner est ennuyeux. Il y a une raison pour laquelle la plupart des programmeurs utilisent toujours des polices à espacement fixe.

Une autre question est de savoir si le texte stylisé doit être utilisé dans le cadre de la syntaxe du langage lui-même. Par exemple, le compilateur doit-il utiliser le fait que certains textes sont stylisés d'une certaine manière pour déterminer que le texte est une déclaration de fonction? Cela peut sembler fou au premier abord, mais des langages comme Python et Fortran utilisent déjà l'indentation comme syntaxe. Néanmoins, je pense qu'il est plus probable que nous continuerons à voir le style basé sur la syntaxe plutôt que l'inverse. De nombreux avantages découlent de la possibilité d'utiliser du texte brut (compilateurs plus simples, indépendance de la plate-forme, préférences du programmeur), et d'autres traditions ont évolué pour rendre le code lisible en l'absence de styles (indentation, lignes vides, caractères marqueurs et fonctions d'édition comme le pliage de code et les menus de navigation).

Je pense que le formatage riche du code source n'est pas très populaire car il est destiné à la saisie d'informations, où la structure et la signification sont beaucoup plus importantes (et plus faciles à saisir également). La fontification, les symboles spéciaux supplémentaires et les espaces blancs ajoutent simplement un bruit visuel inutile. Cela peut être approprié pour la documentation générée.

Il n'y a jamais de guerre à la flamme sans fin sur le même sujet dans le monde de la composition entre ceux qui préfèrent les éditeurs WYSIWYG (comme MS Word) et les systèmes comme TeX (LaTeX).

En général, il n'y a pas de réponse définitive. Tout dépend des outils, des cas d'utilisation et des préférences personnelles.

Des outils tels que Doxygen ou JavaDoc offrent déjà un formatage de code de texte riche. Ils ajoutent également du code hypertexte à des fins de navigation. Vous n'avez pas besoin d'insérer des balises spéciales pour le formatage de base.

Ce n'est cependant pas WYSIWYG.

J'ai peur de dire que cela existe.

Dans le passé, j'ai travaillé sur du code Centura (également connu sous le nom de Gupta ou SQL / Windows - un ancien " 4GL "). Il n'était pas vraiment possible de modifier le code Centura dans un éditeur standard comme le bloc-notes au niveau extrême de mise en forme requis.

Bien qu'il puisse sembler que ce serait une bonne idée d'avoir un fichier source formaté comme ceci, j'ai trouvé que le développement était assez restrictif et douloureux.

En outre, la mise en forme a souvent causé des problèmes lors de la fusion dans le contrôle de code source.

En plus des autres réponses, je voudrais souligner qu'en plus des difficultés techniques liées à l'utilisation d'un formatage riche, il est également un objet de préférence personnelle.

Si vous modifiez du texte brut, vous pouvez choisir les polices et les couleurs que vous aimez et elles sont définies automatiquement. Si vous éditez du texte enrichi, que se passe-t-il si vous n'aimez tout simplement pas des couleurs et des polices particulières définies manuellement?

Je pense que c'est parce que personne n'a encore séparé la lecture et l'écriture de code. Au moins, cela ne devient pas courant. Parfois, vous devez lire du code que vous avez touché il y a longtemps ou du code créé par d'autres développeurs. Vous devrez probablement passer beaucoup de temps jusqu'à ce que vous soyez prêt à changer un seul octet dans cette source. Il peut s'agir d'un mode "lecture" qui peut faire tout ce qui est nécessaire pour une meilleure compréhension (taille de police, reformatage, sous-script, super-script, etc.). Lorsque vous êtes prêt, l'éditeur peut passer en mode "écriture" et être moins restrictif et obéir davantage à "la règle de la moindre surprise"