• [^] # Re: ... et pas qu'un ...

    Posté par (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -3.

    Être obligé de jongler avec plusieurs langages en fonction du type d'application à développer ? Non merci, je préfère pouvoir développer tout type d'application en utilisant un seul langage ; c'est beaucoup plus efficace.

    Ou pas.
    Mon stage de fin d'études c'était justement la migration d'une application mono-langage (Progress 4GL) à une pile de langages plus spécialisés (Java, HTML, JS, SQL). Eh bien la pile de langages était infiniment plus facile à comprendre et utiliser que l'espèce de soupe qui prétendait tout faire, des requêtes à la BDD aux effets présentés à l'utilisateur.

    Non mais, sérieux, comparer le C++ avec cette horreur de PROGRESS...

    Après, je n'impose à personne de n'utiliser qu'un seul et même langage. S'il y en a qui préfèrent en utiliser plusieurs, grand bien leur fasse, mais je ne vois pas au nom de quel principe, parce que à eux, ça leur réussit, il ne serait pas possible de faire tout aussi bien avec un seul langage, à fortiori lorsqu'il s'agit du C++...

    Ça fait la troisième fois (en comptant la version Node.js) qu'ont dit que mon code est nettement perfectible (ce dont j'ai parfaitement conscience, comme je l'ai à maintes fois indiqué). Je veux bien, mais est-ce que quelqu'un aurait la bonté de me montrer ne fût-ce qu'un exemple de ce qui ne va pas, et comment le corriger, histoire que j'ai l'occasion d'améliorer mon code ? Ou alors je vais finir pas penser que mon code n'est peut-être pas aussi mauvais que certains le prétendent !

    Je vais être sec aussi, mais en ce qui concerne ton code Java, il n'y a tellement rien qui va que te l'expliquer en détail est un travail si énorme que c'est décourageant.

    J'avais prévenu que je n'y connaissais pas grand chose en Java !

    Si je prends juste en exemple le TODO MVC :

    Le fichier s'appelle main.java mais ne contient pas de classe publique qui s'appelle main.

    OK.

    Le fichier n'est pas dans un package.

    OK.

    Deux classes (package-protected) dans le même fichier.

    Là, je ne comprend pas trop.

    Tu utilises des new String("...").

    Ah. Ça pose problème ? Si je fais String toto = "tutu", je suis bien obligé de faire un toto = new String("...") si je veux réutiliser toto, non ?

    int index = this.index; ?!

    D'ailleurs tu passes ton temps à masquer la variable de classe index avec des variables locales index.

    Comme je modifie this.index juste après, il fallait que je stocke sa valeur. Bon, j'aurais pu modifier this.index à la fin, et l'utiliser à la place de la variable locale, mais je ne trouvais pas ça conceptuellement très propre.

    Tu n'utilises pas les possibilités de l'API standard (l'itérateur ligne 43, le while ligne 197 par exemple, ou tout le bloc de if / else if à partir de la ligne 230).

    Pour l'itérateur, je ne connaissais pas. Pour la boucle if/else, je pense que c'est par rapport au switch. C'est pour rester compatible avec Java < à 1.7, vu que les switch avec des String ne sont disponibles qu'à partir de cette version. Bon, maintenant, si on me dit que ce n'est pas la peine de rester compatible avec ces versions-là, je switcherai volontiers du if/else au switch.

    if ( false ) { !?

    Je mets à true pour certains essais, comme ça la todo list n'est pas vide au lancement.

    La ligne 273 ressemble beaucoup à une boucle infinie.

    Parce que c'en est une. Si j'ai bien compris, il faudrait que le new rende tout de suite la main, et qu'il soit suivi d'une fonction genre launch() qui, elle, serait bloquante.

    Ton main lance Exception, ce qu'il ne devrait pas faire, et en plus rien dans ton code ne déclare que cette Exception devrait être lancée.

    Il devait y avoir une méthode qui lançait Exception dedans à un moment, je pense...

    Tu appelles des méthodes avec leur package complet au lieu de les importer (info.q37.xdhq.XDH.readAsset).

    Ah, je ne savais pas que c'était déconseillé.

    Tout est ultra-manuel : génération de XML à la main en dur dans le code, méthode escape que tu as réinventé, etc.

    Toute la partie XML a été fait en mode quick and dirty, parce que je n'ai pas trouvé de bibliothèque simple à installer qui le prenne en charge, et que, de toute manière, rien n'est imposé à l'utilisateur, pour peu qu'il fournisse à la fin une chaîne contenant du XML valide. Par contre, s'il existe une méthode toute faite pour remplacer mon escape(), je suis preneur...

    Tout est en vrac dans un seul fichier : personnellement je ne comprends pas ce que fait ce code à sa simple lecture.

    Je voulais éviter la multiplication des fichiers, vu que ça a tendance à effrayer...

    J'imagine que le index de la classe TodoMVC pourrait être nullable pour gérer le cas particulier au lieu d'utiliser la valeur spécifique -1.

    Je pense que oui... Ceci dit, je ne pensais pas qu'on pouvais nuller un type primitif...

    Dans la méthode push tu modifies ton paramètre xml.

    C'est sûr que la méthode que tu proposes est mieux, mais il me semblait avoir essayé un truc similaire, et cela ne fonctionnait pas. Peut-être un problème dû à l'utilisation d'une version antérieure de Java ?

    La logique contient des triples négations : dans handleCount tu as un else sur une condition négative qui active un truc qui s'appelle HideBidule. Au final ça fait quoi ?

    Si le nombre de todos actifs est différent du nombre total de todos, alors ça signifie qu'il y a des todos achevés, et donc il faut afficher le bouton permettant leur effacement, sinon il faut le cacher.

    D'ailleurs le projet s'appelle TODO MVC mais n'est pas du tout du MVC ?!

    C'est le but. Le projet dont est tiré l'application s'appelle TodoMVC et met effectivement en œuvre une architecture MVC, parce que c'est requis par la plupart des frameworks les plus populaires. Mais pourquoi utiliser cette architecture si l'on peut s'en passer ?

    Je passe sur les détails comme le formatage, la présence d'un System.out, l'import de packages complets ou le manque d'accolades.

    On utilise quoi, alors, à la place de System.out pour afficher quelque chose dans la console ?

    Je passe aussi sur ton API qui me semble très étrange, comme ces méthodes qui attendent un tableau de tableau de String.

    En fait, c'est pour passer des paires de Strings, chaque paire étant une clef associée à une valeur. Si on passe deux tableaux de String, un pour les clefs, l'autre pour les valeurs, on perd le lien direct clef/valeur. Du coup, qu'est-ce que je peux utiliser à la place d'un tableau de tableau de String ?

    (non testé).

    (et pourtant, il n'y a vraiment pas grand chose à installer pour ça...).

    En tout cas, merci d'avoir pris le temps de suggérer des améliorations. Je modifierais les fichiers concernés en conséquence, une fois que j'aurais terminé le binding PHP (je préviens d'avance, je ne m'y connais pas plus en PHP qu'en Java).

    Zelbinium: pour la génération qui crée, pas celle qui scrolle...