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

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

    J'avais prévenu que je n'y connaissais pas grand chose en Java !
    [...]
    je préviens d'avance, je ne m'y connais pas plus en PHP qu'en Java).

    Mais si tu n'y connais rien, pourquoi tu te tapes les bindings toi-même ? Tu sais que tu vas avoir des versions toutes bancales qui feront peur plus qu'elles donneront envie. Si tu as une lib libre de qualité en C++, tu ne devrais avoir aucun mal à convaincre des développeurs plus expérimentés de faire les bindings dans les langages qui les intéressent.

    Pour le reste, dans l'ordre :

    • Tu ne mets pas 2 classes de premier niveau dans le même fichier en Java. C'est techniquement possible, mais personne ne fait ça.
    • Il n'y a pratiquement aucune raison de faire new String() en Java. En fait, je n'en vois aucune.
    • Il n'y a aucun problème à utiliser un champ dans une méthode.
    • Dans tous les cas, une variable locale ne devrait jamais avoir le même nom qu'un champ – j'imagine que c'est la même chose en C++ ?
    • L'itérateur, c'est Java 5 (2004).
    • Aucun intérêt à faire du Java < 8 en 2018 sur un nouveau projet.
    • On ne commite pas les if de test, ou alors on les commente – j'imagine que c'est la même chose en C++ ?
    • Tu as bien compris pour le new.
    • Un code de démo doit être le plus clair possible et illustrer les bonnes pratiques. Si c'est plus clair avec 15 fichiers qu'avec un seul, alors ça doit être dans 15 fichiers – j'imagine que c'est la même chose en C++ ?
    • On ne peut pas « nuller » un type primitif, mais il y a les classes enveloppes (pour toi Integer) pour ça. Depuis Java 5 (2004) le boxing et l'unboxing (conversion classes enveloppes ↔ types primitifs) sont automatiques.
    • Le code que j'ai proposé pour le paramètre xml fonctionne normalement depuis Java 1.0.
    • Ton explication sur les triples négations n'enlève rien au fait que c'est une triple négation. Pour des raisons de lisibilité (et sauf cas très exceptionnel), un if/else à branches équilibrées (ici c'est le cas) devrait être de la forme if (a == b) { X() } else { Y() } et non if (a != b) { Y() } else { X() }. Et les actions devraient avoir un sens positif (ShowBidule) et pas négatif (HideBidule). C'est valable dans tous les langages, dont le C++.
    • Un code qui n'est pas un pur test devrait utiliser un logger (y'en a un dans l'API standard).
    • Un lien clé-valeur en Java, c'est une Map...
    • J'ai essayé de le tester. J'ai eu le même genre d'emmerdes que barmic dans ce commentaire, sauf que moi j'ai écris mon retour sur ma pause au boulot. Je n'avais pas 1h à passer pour faire marcher le bordel.

    La connaissance libre : https://zestedesavoir.com