Skip to content
  • Éloïs @librelois ·

    L13: unwrap() c'est le mal absolu, c'est a bannir sauf dans les cas ou tu est certain a 100% que ça ne peut pas être None/Err. Ce qui n'est pas le cas ici car tu unwrap un message reçu, si j’envoie un message non textuel a ton serveur je le fait panic, très grosse faille de sécurité !

    Utilise plutot un if let, si tu rentre dans le if tu fait ton traitement, et pas de else du coup si tu reçoit un message non-textuel il sera juste ignoré.

    L16-19: Transformer un Result en Option c'est mal, d'autant qu'ici cette transformation ne te sert a rien. Tu peut faire un pattern matching sur ton guess que se soit un Result ou une Option.

    L22-29 : Quand on traite seulement 2 cas possibles avec un seul ou l'on a besoin de déstructurer l'expression on passe par un if let. Prend l'habitude d'utiliser la clause if let c'est beaucoup plus rusty et ultra utilisé partout et tout le temps.

    L16 et L22: tu n'a pas besoin de déclarer les types de guess et response, surtout qu'ici on devine de suite le type a la lecture, donc ça alourdi le code pour rien ;)

    bon je chipote sur des détails hein (sauf pour la faille de sécu), mais sur 40 lignes si on veut trouver de quoi dire faut bien chipoter un peu ^^

    Edited by Éloïs
  • Hugo Trentesaux @HugoTrentesaux ·

    Merci beaucoup !

    Pour la faille de sécurité, j'étais au courant, j'aurais dû le mettre en commentaire parce que j'avais oublié :)

    Je vais redécouvrir le if let, ça me fera du bien, j'avais oublié depuis l'été dernier, quand j'ai lu le rust book.

    Pour les types, j'ai vu les endroits où ils pouvaient être inférés (comme en Julia), mais je préfère annoter parce que je trouve ça plus clair à la lecture. En plus, en Julia, quand le type ne peut pas être inféré, ça compile quand même, mais c'est moins rapide à l'exécution. Ça permet d'écrire des petits scripts destinés à une utilisation unique ou rare extrêmement rapidement. Et ça permet de reprendre un code non typé de quelqu'un qui n'a pas de notions en informatique et de l'annoter pour gagner en vitesse et en sécurité (une annotation de type qui se révèle fausse plante à l'exécution).

    Je suis content que tu "chipotes", ça me permet de progresser. Et je suis content que tu aies relu mon premier programme en Rust parce que c'est toi qui m'avait donné envie de m'y mettre et que j'aime beaucoup l'architecture que tu as proposé pour Durs ! En plus, ça m'a permis de redécouvrir la clause if let. Je vais sûrement corriger mon programme et en faire un article / tutoriel intitulé "Rust, c'est pas si difficile", donc il vaut mieux que mon code soit canonique.

    Merci encore, je suis très heureux à l'idée de travailler avec toi sur le projet Durs et de faire du Rust. J'espère que tu vas passer une bonne semaine malgré tout. Essaye de ne pas trop penser au "temps perdu", ça ne fait rien d'autre que miner le moral. Et je crois que la créativité n'est pas que négativement impactée par la contrainte...

  • Éloïs @librelois ·

    Merci beaucoup pour ton enthousiasme, ça fait très plaisir :)

    Tu le sais probablement déjà, mais en Rust, quand le type ne peut pas être inféré, ça ne compile pas. Donc tu n'a aucun risque a ne pas préciser le type, ni aucune perte de perf possible :)

    Je comprend que c'est plus facile de préciser le type a chaque fois quand on débute en Rust, je faisais pareil au début, mais avec le temps et l'expérience, je ne précise le type que pour les cas complexes, ça permet d'alléger le code :)

    Du coup tu verra que dans Durs, dans les cas pas trop complexes (donc souvent) le type n'est pas précisé. Après c'est une question de style, y a pas de bonne ou mauvaise façon de faire a ce niveau la.

    Merci encore a à très vite :)

    Bonne journée

  • Hugo Trentesaux @HugoTrentesaux ·

    Voilà ma version corrigée. Sans if let, mais avec gestion de tous les cas !
    https://gitlab.com/Hugo-Trentesaux/wsggrs

0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment