Oui, on se doute bien qu'un code syntaxiquement/semantiquement invalide ne va pas s'executer...
Tout comme du code machine inexecutable ne s'executera pas, t'auras ton erreur, et paf.
On se doute mais Timaniac (et quelques autres) ne semblent pas l'avoir compris...
Ca nous avance pas tellement ton histoire la.
ben si, je reformulais quelquechose qui ne semblait pas logique pour certains...
Maintenant, la difference, c'est que ton erreur/warning, en interprete, tu n'as aucun moyen de la detecter avant d'executer le bout de code en question.
et ? c'est quoi le problème ? c'est pour ça que les environnements de dev existent !
Et des tests de couverture de code ecrit manuellement, c'est lourd et difficile a ecrire.
"Suffit" de pas coder avec les pieds, et de commenter ton code (avoir un codex à coté peut être un plus) et adopter des conventions de codage te permet de coder plus vite, mieux, de manière plus lisible, et de ne pas vraiment avoir besoin de tests de couverture de code écrits manuellement... bref faut avoir un minimum de méthodologie
on a pas toujours le choix des delais de developpement/test
là encore, la méthode permet d'avoir moins de cheveux blancs, car en cas de soucis, on arrive plus facilement à voir d'où ça viens, si tant est qu'un soucis arrive puisqu'on a utilisé une méthode de travail qui permet de réduire ce genre de risque.
Si en plus tu dois te rajouter des tests a la con du genre "verifier le type de retour de la fonction", tu t'en sort plus.
bah d'une part t'as pas vraiment à le vérifier (pour php du moins) puisque c'est dynamique et que les fonctions font avec. et, là encore, faut être cohérent dans son processus de dev... avant de donner une variable à une fonction attendant un tableau, il convient de vérifier qu'on lui donne bien un tableau... bref un seul mot d'ordre : méthode
[^] # Re: d'un autre coté ...
Posté par jeffcom . En réponse au journal N'installez pas PHP 5.2.7 !. Évalué à 2.
Tout comme du code machine inexecutable ne s'executera pas, t'auras ton erreur, et paf.
On se doute mais Timaniac (et quelques autres) ne semblent pas l'avoir compris...
Ca nous avance pas tellement ton histoire la.
ben si, je reformulais quelquechose qui ne semblait pas logique pour certains...
Maintenant, la difference, c'est que ton erreur/warning, en interprete, tu n'as aucun moyen de la detecter avant d'executer le bout de code en question.
et ? c'est quoi le problème ? c'est pour ça que les environnements de dev existent !
Et des tests de couverture de code ecrit manuellement, c'est lourd et difficile a ecrire.
"Suffit" de pas coder avec les pieds, et de commenter ton code (avoir un codex à coté peut être un plus) et adopter des conventions de codage te permet de coder plus vite, mieux, de manière plus lisible, et de ne pas vraiment avoir besoin de tests de couverture de code écrits manuellement... bref faut avoir un minimum de méthodologie
on a pas toujours le choix des delais de developpement/test
là encore, la méthode permet d'avoir moins de cheveux blancs, car en cas de soucis, on arrive plus facilement à voir d'où ça viens, si tant est qu'un soucis arrive puisqu'on a utilisé une méthode de travail qui permet de réduire ce genre de risque.
Si en plus tu dois te rajouter des tests a la con du genre "verifier le type de retour de la fonction", tu t'en sort plus.
bah d'une part t'as pas vraiment à le vérifier (pour php du moins) puisque c'est dynamique et que les fonctions font avec. et, là encore, faut être cohérent dans son processus de dev... avant de donner une variable à une fonction attendant un tableau, il convient de vérifier qu'on lui donne bien un tableau... bref un seul mot d'ordre : méthode