J'ai pas mal d'objections là dessus, mais les deux premières sont les plus importantes:Ar-S a écrit :Tu n'as pas tord sur ce doute de "comment débuter en PB". Mais c'est aussi une de ses forces que de proposer plusieurs approches. Pour la grande majorité (à mon avis), nous sommes des hobbyistes de la prog. "Les bonnes manières" sont relatives à nos besoins.
Certes utiliser les nouveaux Callbacks (bind) et les modules peuvent s'avérer utiles et même plus efficaces pour certains projets, mais pour de petits codes/projets, je suis plus d'avis d'y aller au plus simple/facile/traditionnel. Il sera toujours bon d'apprendre et utiliser les fonctions (un peu) plus complexes une fois les rouages de PB maitrisés.
●Une règle assez importante de l'ergonomie, c'est de ne pas multiplier inutilement les possibilités. En général, une option n'est là que parce qu'un développeur n'a pas eu le courage de faire un choix et laisse cette charge à l'utilisateur; avoir le choix n'est que rarement positif, même si cette affirmation n'est pas instinctive du tout.
●La FOOS est un adversaire assez solide : la FOOS, first order optimal strategy, est un concept de game design, les gens de Extra Credits l'ont décrit mieux que je ne pourrais le faire. Ce qu'il faut en retenir : le cerveau est feignant, et une fois qu'il a trouvé une solution qui marche, il a la flemme de chercher mieux.
Aussi, quand je parle de bonnes manières du code, je ne parle pas de nos petites manies. Les règles d'indentation, la façon de nommer les variable, tout ça c'est personnel on on va avoir dur mal à dire qu'une solution est meilleur qu'une autre (même si je sais bien que ma méthode est objectivement meilleure )
Bon, maintenant que j'ai décrit le cadre de ma réflexion, je peux maintenant l'expliquer : Le problème n'est pas d'être pro ou hobbyiste, le problème est de briser ou non le plafond de verre. Et une bonne majorité des membres de ce forum n'y arrivent pas. Pire, ils n'essayent même pas et passent leur temps à se plaindre des outils plutôt que de leur technique. J'ai longtemps réfléchis à ce sujet, parce que ça me parait hallucinant de ne pas chercher à devenir meilleur dans son hobby : c'est un argument que je n'ai jamais entendu qu'ici. Je ne connais pas de footballeur du dimanche qui joue pour perdre, je ne connais pas de peintre amateur qui n'aspire pas à son chef d’œuvre. Mais sur les forums de PB, j'entends souvent ce bon vieux "good enough".
Ma théorie actuelle sur le sujet, c'est justement que les options de PB le rendent accessible, mais sont aussi les plus gros freins à l'évolution de ses utilisateurs. Par exemple, mes trois plus gros facepalm :
Que penser quand on voit des utilisateurs de PB avec 10 ans d'expérience qui utilisent encore la boucle d'event?
Que penser quand on voit des utilisateurs de PB perdu dans 500 lignes de leur propre code spaghetti?
Combien d'heures perdues à débug parce que, par défaut, PB n'est pas en mode explicite? Pire : combien d'utilisateurs ici présents ne savent même pas que PB possède un mode explicite?
Apprendre à utiliser correctement un callback, ça a l'air difficile et on ne se rend pas immédiatement compte des bénéfices à en tirer.
Apprendre à structurer correctement son code dans plusieurs modules, ça prend du temps et les profits qu'on va en tirer ne sont pas évident.
Devoir déclarer ses toutes ses variables, c'est contraignant et ça n'est pas une évidence que ça va régler masse de bugs.
La tradition est l'ennemi justement parce que c'est le contraire du progrès, et beaucoup de gens ne font pas l'effort de passer ces étapes parce qu'elles ne leur apparaissent pas comme nécessaires et c'est pour ça qu'ils stagnent.
Tout ça pour dire que j'ai l'impression que vous inculquez de bien mauvais réflexes à un noob, et que ça ne pourra pas lui faire du bien.