Pourquoi déclarer des variables proches de l'endroit où elles sont utilisées?

J'ai entendu des gens dire que les variables devraient être déclarées aussi près de leur utilisation que possible. Je ne comprends pas ça.

Par exemple, cette politique suggère que je devrais faire ceci:

foreach (var item in veryLongList) {
  int whereShouldIBeDeclared = item.Id;
  //...
}

Mais cela signifie sûrement que les frais généraux de création d'un nouveau intsont engagés à chaque itération. Ne serait-il pas préférable d'utiliser:

int whereShouldIBeDeclared;
foreach (var item in veryLongList) {
  whereShouldIBeDeclared = item.Id;
  //...
}

S'il vous plaît quelqu'un pourrait-il expliquer?

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.

La définition de la variable à l'intérieur de la boucle rend la visibilité locale à cette boucle uniquement. Cela présente au moins 3 avantages pour le lecteur:

1. La définition de la variable et tous les commentaires associés sont faciles à trouver
2. Le lecteur sait que cette variable n'est jamais utilisée ailleurs (aucune dépendance à attendre)
3. Lorsque le code est écrit ou édité, il n'y a aucune chance que vous puissiez utiliser le même nom de variable en dehors de la boucle pour faire référence à cette variable sinon, vous pourriez obtenir une erreur.

Quant au bit d'efficacité, le compilateur est intelligent pour générer la définition en dehors de la boucle dans le code optimisé généré. La variable ne sera pas créée à chaque itération de boucle.

Les gens disent aussi près de leur utilisation que possible , ils ne disent pas que vous devriez avoir à le faire tout le temps, car il y a des cas où déclarer des variables dans le moins de portée entraînera des frais généraux. Les principales raisons de cette déclaration sont la lisibilité et donner des variables la plus petite portée possible.

Bien qu'elle aide à la lisibilité, la lisibilité n'est pas la considération principale dans ce cas, et les IDE modernes n'éliminent pas la nécessité de cette règle.

La principale préoccupation concerne les variables non initialisées. Si vous déclarez une variable trop éloignée de son initialisation, elle vous ouvre à toutes sortes de problèmes potentiels. Vous pourriez vous retrouver accidentellement à travailler avec tout ce qui se trouvait auparavant dans la RAM, ou le résultat d'un calcul plus élevé dans la fonction, ou une initialisation fictive (comme 0) que quelqu'un a mise juste pour empêcher le compilateur de se plaindre. Les gens insèreront du code entre votre déclaration et votre utilisation sans être au courant de vos conditions préalables implicites pour cette variable. Dans le pire des cas, cette utilisation fonctionnera simplement dans vos tests mais échouera sur le terrain.

Déclarer vos variables dans une portée aussi petite que possible et les initialiser à une valeur appropriée juste au moment de la déclaration évitera de nombreux maux de tête de maintenance. Le fait qu'il oblige à une meilleure lisibilité n'est qu'un bel effet secondaire.

Ce n'est pas un "must". C'est juste une opinion, je dois faire quelque chose. Par exemple, j'aime déclarer tous les vars dans les premières lignes de la méthode afin que je puisse commenter ce que je vais faire avec ces vars (bien sûr à moins qu'ils ne soient des compteurs). D'autres personnes, comme vous l'avez entendu, aiment les placer le plus près possible de leur utilisation (comme dans le deuxième exemple que vous avez écrit). Quoi qu'il en soit, le premier exemple que vous fournissez est sûrement une "erreur" (dans le sens où cela entraînera une surcharge comme vous le comprenez).

Il vous suffit de choisir votre chemin et de le suivre.

Vos deux exemples sont du code fonctionnellement différent, ils ne sont pas interchangeables. (Vos exemples dépouillés laissent une distinction sans différence, mais dans un code non trivial, cela fait une différence). La règle que vous visitez est toujours subordonnée à des considérations de portée, comme indiqué par "... que possible".