Discussion :

[theMonz31]

salut

pour moi, le seul interet du For par rappor au foreach est la possibilité
de pouvoir modifier l'objet dans ta boucle for (en le reaffectant (avec constructeur etc...) car dans un foreach, tu ne peux pas modifier
l'objet)

The Monz, Toulouse

[ced600]

En même temps c'est très dangereux de réaffecter l'objet.

Bah ce qui est dangereux est de réaffecter la propriété qui sert à déterminer la fin de la boucle for

Cela me rappelle mes premiers pas en programmation et les boucles infinis que j'obtenais car je m'amusé avec la valeur de test du compteur car au final je l'incrémentais en même tempq que le compteur sans faire exprès suite à une mauvaise programmation

[BigNic]

Effectivement je pense que ce genre d'optimisation est d'un autre temps. La où généralement tu peux gagner un temps significatif avec des optimisations ce sont sur les accès disques éventuellement mais surtout sur les accès réseaux (genre requêtes HTTP ou SQL).

Si tu as un ping de 0.33s entre ton client et ton serveur tu fais 3 requetes et tu as deja un temps de reponse d'une seconde. Ton pouilleme sera le cadet de tes soucis.

Pour moi le foreach est un raccourci de langage sur l'autre syntaxe. Je ne vois pas vraiment d'intérêt à utiliser l'autre syntaxe.

Personnellement dans mon ancienne boite, j'ai pas mal bossé sur les problème de perf et ce que j'en retire c'est qu'il n'y a pas de vérité absolue. Les requêtes HTTP et autes ecritures socket ne ralentisse pas forcément plus qu'un algo mal gaulé ou une boucle mal foutue. Quand à ceux qui code performant et pondent du code imbitable, je les conchie. Cela n'engage que moi, mais je pense qu'il vaut mieux coder de façon à bien montrer les intentions de son code. Puis après, à l'aide d'outils ou non, voir ce qui coute en perf réellement en situation de prod et travailler uniquement la dessus.

[ced600]

+1

La vérité sort de ta bouche

[npuzin]

Quand à ceux qui code performant et pondent du code imbitable, je les conchie. Cela n'engage que moi, mais je pense qu'il vaut mieux coder de façon à bien montrer les intentions de son code.

J'approuve.

J'ajouterais même qu'anticiper les problèmes c'est bien, ajouter des problèmes là où il n'y en a pas, c'est une perte de temps pour toi et pas sympa pour tes collègues.

[ced600]

ajouter des problèmes là où il n'y en a pas

Surtout c'est qu'ajouter des problèmes à version stable c'est vraiment domageable, car on ne sait pas quand est ce que l'on arrivera à en retrouver une

C'est pour cela qu'il faut faire du versionning, mais là je dérive

[Contrec]

Bon merci pour toutes ces reponses. Je clos le sujet.

Merci a tous pour vos points de vue tres interessants.