127.0.0.1 a écrit :



" /> ??



Comment savoir combien il y a de pages dans un livre ?



A: en regardant le numero de la dernière page

B: en lisant toutes les pages et en ajoutant 1 à chaque page lue

C: je ne sais pas lire ni compter







Bon, petit court de programmation pour les nuls.



Pourquoi la solution critiquée est mauvaise ? the_frogkiller a déjà répondu, rien à redire dessus.



Pourquoi faire une deuxième requête en count est une (très) mauvaise idée ? Trois raisons :

1. Ca peut être assez lourd de regénérer une requête count avec les mêmes paramètres que la première. Encore une fois, en milieu pro, la grande, que dis-je ?, l’immense majorité des requêtes sont générées ce qui peut nécessiter un traitement assez lourd (pour peu que ça soit possible - ce qui est loin d’être toujours le cas).
   


2. Une deuxième requête en count sera très rapide dans le cas d’une requête simple, dans celui d’une requête complexe avec jointures multiples c’est pas gagné.
   


3. Absolument rien ne dit qu’entre les deux requêtes (le select simple et le count) il n’y ait pas eu de nouveaux enregistrements…. donc qui donneraient deux réponses différentes (ah, oui, la requête a déjà été exécuté dans le cas donné en critique).
   
   
   
   Conclusion :
   
   Utiliser les outils mis à disposition est toujours le meilleur choix possible. Même effet sans les 3 problèmes cités plus haut. Réinventer la roue ça marche rarement vraiment bien….
   
   
   
   
   
   Sinon je vote pour la réponse A… que fait la que je donne solution mais que ne font pas les autres.
   
   
   
   
   
   Bref, je ne vais pas ergoter, le code est cradingue au possible, mais la solution n’est pas mieux, d’où mon histoire de poutre et de paille. Quand on rapporte un code pour que le monde entier puisse rire de son auteur, la moindre des choses est d’être irréprochable (d’ailleurs j’ai lu 2-3 autres exemples assez drôles du même genre).

Virtual_Spirit a écrit :



Qu’est-ce qui te fait pensé que le code est issue du milieux pro ? Que l’application où tourne le code nécessite des requêtes générées ? Que les traitements sont assez lourds ? Si t’es capable de dire tout ça en regardant 10 lignes de codes félicitation, je pense que tu peux lancer une nouvelle activité : La voyance pour le code.







Si c’est du code de garage le gars fait ce qu’il veut, du moment que ça marche (et son code, pour être très crade) fonctionne.





Pour le reste, rien. Mais rien n’interdit les bonnes pratiques, surtout dans le cas d’une “correction”.







Virtual_Spirit a écrit :



Ah, je pense que t’as pas bien compris l’esprit du blog : montrer des bouts de code un peu dégueulasses pour se marrer, mais pas pour “rire de l’auteur”.



Tous les développeurs écrivent un jour ou l’autre du code dégueulasse, pour des milliers de raisons : manque de temps, manque de formation sur une techno, obligation d’utiliser une librairie pourrie, refactoring (trop) rapide qui laisse du code mort ou des aberrations dans le code, reprise de vieux code horrible et pas le temps de tout réécrire, …



Bref, l’idée c’est de rire de tout ça, parce que tous les développeurs connaissent ça pas de montrer du doigts les auteurs en les traitants de sous-merde.



Les “corrections” ne sont peut être pas toujours les plus optimisés / propre tout ce que tu veux, mais sans connaitre le contexte et le reste du code c’est impossible de juger si la “solution” est la meilleur ou pas à moins de faire comme toi, pleins d’hypothèses qui sont peut être totalement fausses…







Bah, pour moi c’est quand même très axé “Ouh le vilain code ! Riez ! Voilà comment il faudrait faire”.



Et y a pas besoin de connaitre le contexte pour savoir que la solution proposée est presque aussi crade que le code exposé dans ce cas précis.

Virtual_Spirit a écrit :



La voyance pour le code.









Tiens d’ailleurs, monsieur je fais de la voyance de code.



Quelle est la problématique (ce que l’on sait) ?



Une requête mysql a été exécutée, on veut savoir combien de résultats elle a renvoyé.



C’est tout. On ne sait rien d’autre du contexte.





Comment répondre à cette question ?



1)Parcourir les résultats de la requête et incrémenter un nombre à chaque fois. C’est ce que fait l’auteur. Ca fonctionne à 100%, mais ça a effectivement le désavantage d’être lourd à l’exécution si il y a potentiellement beaucoup de résultats. Note que l’on en sait rien et que si c’est 10 résultats y a pas une différence énorme entre ça et les “best practice”.

1. Générer une autre requête par la suite, en count celle-ci comme préconisé par le correcteur. Ouais, ça peut fonctionner. C’est moins dépendant du nombre de résultat pour le temps d’exécution mais ce n’est pas toujours possible. Et surtout : ça ne répond pas à la problématique, ce à quoi tu réponds c’est “A l’instant T+1, combien de résultat cette requête aurait-elle renvoyé ?”, pas “combien de résultats ma requête effectuée à l’instant T a-t-elle renvoyé ?”
   
   
   


2. Utiliser les outils mis à disposition par php qui répondent à ta problématique et qui sont à la fois rapides et totalement indépendant du nombre de résultat.
   
   
   
   
   
   Fais ton choix ! A titre personnel, je préfère un code rapide et fonctionnel. Si je ne peux pas l’avoir je préfère encore un code lent mais fonctionnel à un code aux résultats aléatoires. Pour insérer des bugs super chiants à tracer et à débuguer dans un projet y a pas mieux " />