D'abord, merci de contribuer du code, c'est sympa.
Merci de t'y intéresser :-).
Pour le feedback :
1) Il y a genre aucun commentaires dans le code, dur pour qui que ce soit de t'aider si ils ne peuvent pas comprendre ce que le code fait
En fait, je ne cherche pas de contributeurs, car cela poserait des problèmes de licence. Le code est, par défaut, disponible sous AGPL, mais c'est sous une autre licence, moins contraignante, qu'il est disponible pour mes clients. Je peux publier ce code sous n'importe quelle licence, car j'en suis l'unique auteur. Mais s'il contient des contributions de tiers, cela sera beaucoup plus compliqué...
En fait, bien plus que des contributeurs, c'est des utilisateurs que je recherche, qui puisse me remonter les éventuels problèmes. C'est d'ailleurs pour pour cela que j'ai migré mon code sur github, qui est l'une, voire la plus populaire des forges logiciels, pour que les utilisateurs disposent d'outils qui leurs sont familiers.
Ceci dit, je pense que ce qui manque à mon code, c'est bien plus une documentation expliquant les principes généraux que des commentaires. Mais, comme c'est moi qui ai écrit le code et que je l'utilise tous les jours, je ne suis probablement pas objectif...
2) Les noms de variables/methodes/etc... sont imbitables pour le commun des mortels (aucune idée de ce que lcl, qCDTOR, etc... sont)
En effet, d'où ce que j'écrivais ci-dessus, de la nécessité d'avoir une documentation explicative. J'envisage de publier une série d'utilitaires mettant chacun en avant une fonctionnalité bien précise de mes bibliothèques, et d'en écrire la documentation correspondante à ce moment-là. Mais, compte tenu du travail que cela représente, il faudrait qu'il y ai une réelle demande à ce niveau-là, ce dont je ne suis pas convaincu, pour me lancer.
3) Exposer un parser écrit en C++ à des documents venant de sources inconnues ( = internet) est super dangereux, est-ce que tu as fais des passes de fuzzing sur ce parser au minimum ?
Bon, je vais me faire huer, mais la vérité est que j'écris très peu de tests en tant que tels. Ce n'est pas que j'y sois opposé, et je conseille fortement d'en écrire, mais le fait est, et ça fait un paquet d'années que je développe, que j'ai très bien pu m'en passer jusqu'à présent. Ceci dit, je factorise mon code très en amont du développement, ce qui explique peut-être cela. Le préprocesseur, et le parser que lequel il s'appuie, qui font l'objet de ce journal, sont récents en tant que addonNode.js, mais le code C++ qu'il y a derrière existe depuis probablement presque dix ans, et est mis en œuvre dans tous les développements que j'ai réalisés depuis. C'est donc du code qui est utilisé très intensivement. Certes, ça ne garantit rien en soi, mais, plus un code a d'utilisateurs, plus rapidement les problèmes sont détectés (et, à priori, corrigés), et c'est pour cela que je cherche à accroître le nombre de ses utilisateurs...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Mais je t'en prie...
Posté par Claude SIMON (site web personnel) . En réponse au journal Code natif et Node.js - parser et préprocesseur XML. Évalué à 1.
Merci de t'y intéresser :-).
En fait, je ne cherche pas de contributeurs, car cela poserait des problèmes de licence. Le code est, par défaut, disponible sous AGPL, mais c'est sous une autre licence, moins contraignante, qu'il est disponible pour mes clients. Je peux publier ce code sous n'importe quelle licence, car j'en suis l'unique auteur. Mais s'il contient des contributions de tiers, cela sera beaucoup plus compliqué...
En fait, bien plus que des contributeurs, c'est des utilisateurs que je recherche, qui puisse me remonter les éventuels problèmes. C'est d'ailleurs pour pour cela que j'ai migré mon code sur github, qui est l'une, voire la plus populaire des forges logiciels, pour que les utilisateurs disposent d'outils qui leurs sont familiers.
Ceci dit, je pense que ce qui manque à mon code, c'est bien plus une documentation expliquant les principes généraux que des commentaires. Mais, comme c'est moi qui ai écrit le code et que je l'utilise tous les jours, je ne suis probablement pas objectif...
En effet, d'où ce que j'écrivais ci-dessus, de la nécessité d'avoir une documentation explicative. J'envisage de publier une série d'utilitaires mettant chacun en avant une fonctionnalité bien précise de mes bibliothèques, et d'en écrire la documentation correspondante à ce moment-là. Mais, compte tenu du travail que cela représente, il faudrait qu'il y ai une réelle demande à ce niveau-là, ce dont je ne suis pas convaincu, pour me lancer.
Bon, je vais me faire huer, mais la vérité est que j'écris très peu de tests en tant que tels. Ce n'est pas que j'y sois opposé, et je conseille fortement d'en écrire, mais le fait est, et ça fait un paquet d'années que je développe, que j'ai très bien pu m'en passer jusqu'à présent. Ceci dit, je factorise mon code très en amont du développement, ce qui explique peut-être cela. Le préprocesseur, et le parser que lequel il s'appuie, qui font l'objet de ce journal, sont récents en tant que addon Node.js, mais le code C++ qu'il y a derrière existe depuis probablement presque dix ans, et est mis en œuvre dans tous les développements que j'ai réalisés depuis. C'est donc du code qui est utilisé très intensivement. Certes, ça ne garantit rien en soi, mais, plus un code a d'utilisateurs, plus rapidement les problèmes sont détectés (et, à priori, corrigés), et c'est pour cela que je cherche à accroître le nombre de ses utilisateurs...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...