Source en français

LittleBopLittleBop Member
juillet 2011 modifié dans Discussions générales
Bonjour,

je parcours un peu la structure (répertoires, noms de fichiers "theme", ...) d'un site PluXML ainsi que le code source associé (classes, méthodes, ...) et je suis étonné de voir énormément de français d'une part mais presque surtout mélangé à de l'anglais !

J'imagine qu'il y a une question historique, peu importe, est-il prévu un changement drastique à ce niveau ou pas du tout ?

Autre point plus ou moins lié (plutôt moins que plus), les constantes (chaînes) utilisées sont répétées un peu partout (55 occurences de 'categorie' par exemple), quid d'un changement de constante ('category', ...) ?
Question, pourquoi pas un jeu de constantes numériques dont le nom est évocateur ? (référencer un élément du langage (constante) plutôt qu'une chaîne est plus aisé dans un IDE) 
define('HOME_PAGE_TYPE', n+1);
define('STATIC_PAGE_TYPE', n+1);
define('CATEGORY_PAGE_TYPE', n+1);
Merci,

p.s. ce ne sont ici que des questions pour comprendre la philosophie de dev ;-)

Réponses

  • StéphaneStéphane Member, Former PluXml Project Manager
    Bonjour

    Effectivement c'est l'historique de PluXml qui justifie la présence de français et d'anglais dans les sources. La tendance est d'aller vers l'anglais pour une meilleur compréhension internationnalle des sources. Certaines modifications sont faciles à faire (il faut juste du temps et ce n'est pas une priorité), d'autres modifications sont plus sensibles car elles générent de la regression et demandent des tests unitaires importants. Quand on change le nom d'une variable il faut mesurer l'impact sur tout le reste du code.

    Pour les constantes de chaines si elles peuvent se répeter c'est à cause de l'internationnalisation. Dans certaines langues la traduction est différente suivant les contextes.
    De plus si pour une raison quelconque (due à des évolutions) on souhaite sur une page mais pas sur une autre changer une constante, il faut que cela reste possible. Si on modifie d'un coté il ne faut pas que ça casse tout ce qu'il y a à coté.

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • LittleBopLittleBop Member
    Concernant l'évolution FR->EN, oui, je suis bien conscient des problèmes de regression que ça engendre ainsi que ce qu'un changement d'API a comme effet :-)

    Pour les constantes, je ne suis pas sûr qu'on parle de la même chose, je parlais pour ma part (en citant l'example 'category') des chaînes qui discrimine le type de page à récupérer ou bien les clés du tableau aConf et ce genre de chose. Pas d'internationalisation ici (sauf si j'ai loupé un épisode)
  • StéphaneStéphane Member, Former PluXml Project Manager
    Je ne comprends pas ce que tu évoques sur les chaines. Peux-tu détailler stp ?. Ton point de vue m'interesse.

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • LittleBopLittleBop Member
    juillet 2011 modifié
    Hmm, je vais essayer !

    Pour expliquer pourquoi j'en suis arrivé à cette question, je peux juste dire que quand je vois des strings en dur dans du code, je commence directement à bondir, 2 problèmes majeurs à ça :

    internationalisation (message à vocation plutôt applicative)
    factorisation et uniformité des messages (plutôt pour un framework)

    Use case 1, je met des strings en dur dans mon code pour un formatage de date, un séparateur, un titre, ... n'importe quoi, l'internalisation est foutue (pas les mêmes conventions linguistiques etc.) on peut même aller jusqu'à du contenu textuel pur.

    Use case 2, je décide de changer mon message d'erreur X, or il se trouve à différents endroits dans mon code, je dois donc faire une recherche manuelle, isoler les références à cette chaîne dans les commentaires (le cas échéant) de celles que je souhaite réellement changer, risque d'oubli important, productivité faible, ...

    Pour une meilleure gestion du Use case 2, si j'avais utilisé des constantes (define) et fait référence à celles ci dans mon code, un seul endroit à changer et tout le code en profite, aucun risque d'oubli, productivité maximale.

    Pour le cas que je décrivais dans mes messages précédents, il se rapproche du case 2 mais peut être encore plus optimisé.
    lorsque je fais aConf ou aConf, il s'agit d'identifiants du framework utilisables par l'utilisateur (exemple: 'link') ou pas (exemple: 'category'). Si je veux changer demain, c'est foutu, le mec verra son appli péter at runtime dans son code utilisateur parce que ces tokens ont changé (du coup, on les changes jamais), c'est peu extensible, dupliqué 'n' fois dans le code du framework, difficilement documentable, on paie le coût (lourd) de manipulation de chaînes etc.

    Maintenant, si j'utilise des identifiants numériques constants documenté et accessibles à l'utilisateur, je ne manipule que des références à la même déclaration, l'utilisateur aussi, si je veux changer le nom, d'une ton IDE détectera les références dans ton framework (s'il est pas trop mauvais ?!) (pas trop d'intérêt mais admettons), le code utilisateur ne pétera plus au runtime mais à la compile (pour le cas des langages compilés, mais en fait en interprété avec un bon IDE, on peut détecter lors du dev statique ce genre de chose (référence à une constante non accessible)

    Donc concrètement,
    define('CATEGORY_PAGE_TYPE', 0);
define('HOME_PAGE_TYPE', 1);
define('STATIC_PAGE_TYPE', 2);

/**
 * used to display title as simple text
 */
define('TEXT_TITLE_MODE', 0); 

/**
 * used to display title as hypertext link
 */
define('LINK_TITLE_MODE', 1);
define('DEFAULT_TITLE_MODE', TEXT_TITLE_MODE);
    Au niveau du framework, on switch sur ces defines (switch sur un int plus efficace que sur une chaîne)
    switch($pageType){
case CATEGORY_PAGE_TYPE:
// ...
case HOME_PAGE_TYPE:
// ...
case STATIC_PAGE_TYPE:
// ...
}
    Au niveau user, on référence des identifiants du framework, on fait pas de faute de frappe (auto complétion sur les constantes avec un bon IDE, ...)
    plxShow->mainTitle(LINK_TITLE_MODE);
    J'espère que j'ai été plus clair et convaincant ;-)

    p.s. désolé pour les potentielles erreurs de syntaxe ou autre niveau PHP, ça n'est pas mon langage de prédilection, j'utilise plus que je ne développe avec !
  • StéphaneStéphane Member, Former PluXml Project Manager
    ok je comprends mieux avec ton explication. tu ferais pas du C++ toi :-)
    je suis d'accord avec toi mais cela reste applicable que pour des constantes.
    pour des variables du type aConf ou aConf, ces variables sont alimentées à partir du contenu des fichiers xml qui correspondent au choix et paramétrage utilisateur.
    si tu regardes dans le fichier /config.php, on a 
    # profils utilisateurs de pluxml
define('PROFIL_ADMIN', 0);
define('PROFIL_MANAGER', 1);
define('PROFIL_MODERATOR', 2);
define('PROFIL_EDITOR', 3);
define('PROFIL_WRITER', 4);
    ce qui correspond exactement à ce que tu expliques.
    Maintenant certains choix et façon de programmer sont liés à l'historique de PluXml.
    Revoir le code d'un projet bien avancé pour qu'il colle aux règles de l'art de la programmation, c'est un chantier à lui seul, mais qui vaut sans aucun doute le coup d’être fait. Après il faut être judicieux dans les define que l'on choisit. Ce n'est pas toujours nécessaire et ça consomme de la mémoire inutilement, alors qu'une chaîne en dur, fait gagner des cycles de traitement et de la mémoire. Je te rappelle que le contexte ici est un langage interprété et non compilé.

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • LittleBopLittleBop Member
    Je fais du Java, mais oui, je viens plutôt du monde compilé qu'inteprété.

    Ce que tu dis au niveau de la conso RAM me surprend fortement, je vois pas bien comment 4 int vont prendre plus de RAM que 4 strings.
    Tes strings doivent être internées (la gestion des strings, c'est l'enfer, je sais pas si l'interprétation améliore la chose, pas d'expérience pour le dire) et donc rester en RAM aussi d'une manière ou d'une autre.

    Pour le aConf, à part que tu auras un tableau d'int au lieu de string, quel problème (peut-être un truc lié à PHP que je ne perçoit pas)

    aConf[CATEGORY_PAGE_TITLE] ou aConf[HOME_PATE_TITLE], pas possible ?

    Bref, je comprend bien qu'une part des remarques faites ici doit provenir de l'historique et c'est bien naturel ;-)
  • StéphaneStéphane Member, Former PluXml Project Manager
    Java: j'étais pas loin en disant C++ :)

    la différence entre un aConf[PAGE_TITLE] et un aConf est que dans le 1er cas, tu obliges à aller chercher d'abord à quoi correspond PAGE_TITLE, puis après tu renvoie la valeur du tableau, alors qu'avec aConf tu y accède de suite.
    bon je t'avoue que même si je partage ton avis, ce genre d'approche ne me semble pas forcément justifiée sur un projet comme pluxml. c'est vraiment se rajouter des contraintes en plus et qui ne rend pas obligatoirement le code plus lisible et compréhensible pour des contributeurs qui ne sont pas des programmeurs avisés ou expérimentés.

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • LittleBopLittleBop Member
    juillet 2011 modifié
    Je comprend la nuance que tu évoques qui vient de l'aspect interprété de PHP même si je suis surpris que la résolution des constantes ne soit pas "gratuite" (en fait, j'emet un doute mais vu que je connais pas... ;-) ), c'est sûr que compilé, y a pas plus performant !!

    ne rend pas obligatoirement le code plus lisible et compréhensible pour des contributeurs qui ne sont pas des programmeurs avisés ou expérimentés.
    Est-ce réellement un désavantage ;-) ? (cette question ne requiert pas de réponse !!)
  • RubénRubén Member
    Moi je suis pour que la source reste en français.
    Le français est une langue internationale depuis plus longtemps que l'anglais.
    Et c'est pas parce que les anglophones ont du mal avec les langues qu'on va faire le travail de traduction pour eux.
    PS : je suis étudiant en langues étrangères alors n'y voyez pas de chauvinisme ou autre.
  • StéphaneStéphane Member, Former PluXml Project Manager
    Heu les français sont loin d'etre une référence en matiere de langues étrangères.
    Enfin je crois... :p

    Consultant PluXml

    Ancien responsable et développeur de PluXml (2010 à 2018)

  • RubénRubén Member
    En Angleterre l’apprentissage d'une langue étrangère n'est pas obligatoire alors qu'en France on en apprend au minimum deux.
    Après c'est vrai que les français n'ont pas le même niveau d'anglais que des néerlandais mais ils ont quand même des connaissances.
  • LittleBopLittleBop Member
    C'est un point de vue...

    Écrire du code en français est une erreur à mon sens dans la mesure où les mots clés des langages sont en anglais, les librairies standard aussi, n'importe quelle lib digne de ce nom... aussi... Donc à la limite faire sa lib en français, mais le foutoir final nuit à la cohérence globale du code, à la compréhension (faux amis potentiel (mot d'une lib standard et de notre code français) pas d'accent, même si les langages peuvent accepter l'UTF-8, c'est loin d'être une recommandation vu ce que les OS, IDE, développeur, ... font de l'encodage des fichiers.)

    Bien souvent l'usage du français dans le code abouti un mélange bien joyeux de franglais ("getChamps", "isInitiliase", ...), le franglais est une abération.

    Après, que la documentation et/ou les commentaires soient écrite en anglais, je ne dis pas, pourquoi pas même si pour être répandu à une communauté je trouve que c'est une erreur.

    Quand au caractère international de la langue français et l'antériorité de ce caractère... *ahem*...
  • RubénRubén Member
    Une langue internationale est une langue parlée sur tous les continents de manière officielle.
    Sinon on peut avoir les commentaires en bilingue, comme à Toulouse/Perpignan les plaques de rue ^^
  • BloodyBloody Member
    Rubén et LittleBop, je ne sais pas si débat doit vraiment avoir lieu sur ce forum. :lol:
Connectez-vous ou Inscrivez-vous pour répondre.