Pourquoi sont des fichiers de texte plats de l'état de l'art pour représenter le code source?
Assurez-vous - le préprocesseur et le compilateur besoin de voir un fichier plat représentation du fichier, mais c'est facilement créé.
Il me semble qu'une certaine forme de XML binaire ou de données peut représenter beaucoup d'idées qui sont très difficiles à suivre, sinon.
Par exemple, vous pouvez inclure des diagrammes UML à droite dans votre code. Ils pourraient être générés de manière semi-automatique, et commentée par les développeurs pour mettre en évidence des aspects importants de la conception. Les diagrammes d'Interaction, en particulier. Heck, l'intégration de n'importe quel utilisateur de dessin pourrait rendre les choses plus claires.
Une autre idée est d'incorporer des commentaires de révision du code de droit dans le code.
Il pourrait y avoir toutes sortes d'aides à la fusion de plusieurs branches plus facile.
Quelque chose que je suis passionné n'est pas seulement le suivi de la couverture de code, mais aussi de regarder les parties de code couvert par un test automatisé. La partie la plus difficile est de garder la trace de ce code, de même que la source est modifié. Par exemple, le déplacement d'une fonction à partir d'un fichier à un autre, etc. Cela peut être fait avec les Guid, mais ils sont plutôt intrusive pour intégrer le droit dans le fichier texte. Dans une riche format de fichier, ils pourraient être automatique et discrète.
Alors, pourquoi ne sont-ils pas IDEs (à ma connaissance, de toute façon) qui vous permettent de travailler avec du code dans ce sens?
EDIT: le 7 octobre 2009.
La plupart d'entre vous a eu très accroché sur le mot "binaire" dans ma question. Je la retirer. Image XML, très peu de marquage de votre code. L'instant d'avant de vous remettre à votre normal de préprocesseur ou le compilateur, vous dépouiller de toutes les balises XML, et passer sur le code source. Dans ce formulaire, vous pouvez toujours faire toutes les choses normales pour le fichier: diff, de fusion, d'éditer, de travailler dans un simple et un minimum d'éditeur, de les introduire dans des milliers d'outils. Oui, la diff, de fusion, et de modifier, directement avec le minimum de balisage XML, est un peu plus compliqué. Mais je pense que la valeur pourrait être énorme.
Si un IDE existé qui a respecté toutes les XML, vous pouvez ajouter beaucoup plus que ce que nous pouvons faire aujourd'hui.
Par exemple, vos commentaires DOxygen pourrait en fait regarder comme le dernier DOxygen sortie.
Quand quelqu'un voulait faire une revue de code, comme le Code de Collaborateur, ils pourraient marquer le code source, à la place.
Le XML peut même être cachés derrière des commentaires.
// <comment author="mcruikshank" date="2009-10-07">
// Please refactor to Delegate.
// </comment>
Et puis, si vous souhaitez utiliser vi ou emacs, vous pouvez simplement sauter par-dessus les commentaires.
Si je veux utiliser un état-of-the-art de l'éditeur, je peux voir que dans une douzaine de différentes façons utiles.
Donc, c'est mon idée. Ce n'est pas "blocs de construction" de photos que vous faites glisser sur l'écran... je ne suis pas que les noix. :)
