Il s'agit d'une règle de style parmi tant d'autres, et ce n'est pas nécessairement la règle la plus importante de toutes les règles possibles que vous pourriez considérer. Votre exemple, car il inclut un int, n'est pas super convaincant, mais vous pourriez certainement avoir un objet coûteux à construire à l'intérieur de cette boucle, et peut-être un bon argument pour construire l'objet en dehors de la boucle. Cependant, cela ne fait pas un bon argument contre cette règle car, d'abord, il y a des tonnes d'autres endroits qu'il pourrait appliquer qui n'impliquent pas la construction d'objets coûteux en boucle, et deuxièmement, un bon optimiseur (et vous avez étiqueté C #, donc vous avez un bon optimiseur) peut hisser l'initialisation hors de la boucle.
La vraie raison de cette règle est aussi la raison pour laquelle vous ne voyez pas pourquoi c'est une règle. Les gens écrivaient des fonctions qui faisaient des centaines, voire des milliers de lignes et ils les écrivaient dans des éditeurs de texte brut (pensez au Bloc-notes) sans le type de support fourni par Visual Studio. Dans cet environnement, déclarer une variable à des centaines de lignes de l'endroit où elle était utilisée signifiait que la personne qui lisait
if (flag) limit += factor;
n'avait pas beaucoup d'indices sur le drapeau, la limite et le facteur. Des conventions de dénomination comme la notation hongroise ont été adoptées pour aider à cela, tout comme des règles comme déclarer des choses près de l'endroit où elles sont utilisées. Bien sûr, de nos jours, il s'agit de refactoring, et les fonctions sont généralement inférieures à une page, ce qui rend difficile la distance entre l'endroit où les choses sont déclarées et où elles sont utilisées. Vous opérez dans une plage de 0 à 20 et vous dites que peut-être 7 est correct dans ce cas particulier, tandis que le gars qui a établi la règle aurait ADORÉ obtenir 7 lignes et essayait de parler à quelqu'un à partir de 700. Et sur en plus de cela, dans Visual Studio, vous pouvez passer la souris sur n'importe quoi et voir son type, est-ce une variable membre, etc. Cela signifie que le besoin de voir la ligne le déclarer est diminué.
C'est toujours une règle assez bonne, une règle qui est en fait assez difficile à briser ces jours-ci, et que personne n'a jamais défendue comme raison d'écrire du code lent. Soyez sensible avant tout.