Une variable nommée i est-elle inacceptable? [fermé]

Question

En ce qui concerne les conventions de dénomination des variables, les itérateurs doivent-ils être nommés i ou quelque chose de plus sémantique tel que count ? Si vous n'utilisez pas i , pourquoi pas? Si vous estimez que i est acceptable, existe-t-il des cas d’itération où il ne devrait pas être utilisé?

Answer 1

Cela dépend du contexte, je suppose. Si vous parcouriez un ensemble d’objets dans certains collection, alors il devrait être assez évident du contexte ce que vous faites.

for(int i = 0; i < 10; i++)
{
    // i is well known here to be the index
    objectCollection[i].SomeProperty = someValue;
}

Toutefois, si le contexte ne vous a pas clairement indiqué ce que vous êtes en train de faire, ou si vous apportez des modifications à l'index, vous devez utiliser un nom de variable plus représentatif de l'utilisation.

for(int currentRow = 0; currentRow < numRows; currentRow++)
{
    for(int currentCol = 0; currentCol < numCols; currentCol++)
    {
        someTable[currentRow][currentCol] = someValue;
    }
} 

Answer 2

" i " signifie " compteur de boucles " à un programmeur. Il n’ya rien de mal à cela.

Answer 3

Voici un autre exemple de quelque chose qui convient parfaitement:

foreach (Product p in ProductList)
{
    // Do something with p
}

Answer 4

J'ai tendance à utiliser i, j, k pour des boucles très localisées (elles n'existent que pour une courte période en termes de nombre de lignes source). Pour les variables qui existent dans une zone source plus grande, j'ai tendance à utiliser des noms plus détaillés, ce qui me permet de voir à quoi elles servent sans chercher dans le code.

À propos, je pense que la convention de nommage de ces mots vient du tout début du langage Fortran, où j’étais la première variable entière (A - H étaient des flottants)?

Answer 5

i est acceptable, pour certain. Cependant, j'ai appris énormément un semestre d'un enseignant C ++ qui refusait du code qui ne comportait pas de nom descriptif pour chaque variable. Le simple fait de nommer tout, de manière descriptive, m'a obligé à réfléchir davantage à mon code, et j'ai écrit de meilleurs programmes après ce cours, non pas en apprenant le C ++, mais en apprenant à tout nommer. Code Complete a quelques bons mots sur le même sujet.

Answer 6

i c'est bien, mais quelque chose comme ça ne correspond pas:

for (int i = 0; i < 10; i++)
{
    for (int j = 0; j < 10; j++)
    {
        string s = datarow[i][j].ToString(); // or worse
    }
}

Il est très courant que les programmeurs échangent par inadvertance les symboles i et j dans le code, en particulier s'ils ont une mauvaise vue ou si leur thème Windows est "Hot-Dog". C’est toujours une "odeur de code". pour moi, c’est rare quand cela ne se fait pas foirer.

Answer 7

i est si courant qu'il est acceptable, même pour les personnes qui aiment les noms de variables descriptives.

Ce qui est absolument inacceptable (et un péché dans mon livre) utilise i, j ou k dans tout autre contexte que celui d’un index entier dans une boucle .... par exemple.

foreach(Input i in inputs)
{
    Process(i);

}

Answer 8

i est définitivement acceptable. Je ne sais pas quel genre de justification je dois faire - mais je l’utilise tout le temps, et d’autres programmeurs très respectés aussi.

Validation sociale, je suppose:)

Answer 9

Oui, en fait, c'est préférable, car tout programmeur qui lit votre code comprendra qu'il s'agit simplement d'un itérateur.

Answer 10

Quelle est la valeur d'utiliser i au lieu d'un nom de variable plus spécifique? Pour économiser 1 seconde ou 10 secondes ou peut-être même 30 secondes de réflexion et de frappe?

Quel est le coût d'utilisation de i? Peut-être rien. Peut-être que le code est si simple que l’utilisation de i est acceptable. Mais peut-être que, peut-être, en utilisant, je forcerai les développeurs qui utilisent ce code à l'avenir à réfléchir un instant "qu'est-ce que je veux dire ici?" Ils devront penser: "est-ce un index, un compte, un décalage, un drapeau?" Ils devront penser: "ce changement est-il sûr, est-ce correct, est-ce que je serai en retard de 1?"

Utiliser i permet d’économiser du temps et des efforts intellectuels lors de la rédaction de code, mais risque de coûter un effort intellectuel supplémentaire à l’avenir, voire d’introduire par inadvertance des défauts dus à une incompréhension du code.

En règle générale, la plupart des développements logiciels sont liés à la maintenance et à l'extension. Par conséquent, le temps passé à lire votre code dépassera largement le temps passé à l'écrire.

Il est très facile de développer l'habitude d'utiliser des noms significatifs partout, et une fois que vous en avez l'habitude, il ne faut que quelques secondes pour écrire du code avec des noms significatifs, mais vous avez alors un code qui est plus facile à lire, à comprendre , et plus évidemment correct.

Answer 11

J'utilise i pour les boucles courtes.

Si tout va bien, c'est parce que je trouve tout à fait invraisemblable que quelqu'un puisse voir une déclaration de type itérateur, avec initialiseur, puis trois lignes plus tard déclarent que ce que la variable représente n'est pas clair. Ils font juste semblant, car ils ont décidé que les "noms de variables significatifs" doit signifier "noms de variable longs".

La raison pour laquelle je le fais réellement, c’est parce que je trouve que l’utilisation de quelque chose qui n’est pas lié à la tâche spécifique à accomplir, et que je n’utiliserais que dans un petit périmètre, me permet de ne pas craindre d’utiliser un nom trompeur, ou ambigu, ou sera un jour utile pour quelque chose d’autre plus vaste. La raison pour laquelle il s'agit de "i" plutôt que & q; q " ou "compter" est juste convention empruntée aux mathématiques.

Je n'utilise pas i si:

• Le corps de la boucle n'est pas petit ou
• l'itérateur fait autre chose que d'avancer (ou de reculer) du début d'une plage à la fin de la boucle:

i ne doit pas nécessairement aller par incréments de 1 tant que l'incrément est cohérent et clair et peut bien sûr s'arrêter avant la fin de l'itérande, mais s'il change de direction ou n'est pas modifié par une itération de la boucle (y compris l'utilisation diabolique de iterator.insertAfter () dans une boucle de transfert), j'essaie de me rappeler d'utiliser quelque chose de différent. Cela signifie "qu’il ne s’agit pas simplement d’une variable de boucle triviale, c’est pourquoi il se peut que ce ne soit pas une boucle triviale".

Answer 12

Si le "quelque chose de plus sémantique" est " iterator " alors il n'y a aucune raison de ne pas utiliser i; c'est un langage bien compris.

Answer 13

Je pense que je suis tout à fait acceptable dans les situations de type boucle. J'ai toujours trouvé que c'était assez standard et que je n'étais jamais vraiment confronté à des problèmes d'interprétation lorsque je l'utilisais dans ce cas. Les boucles foreach deviennent un peu plus difficiles et je pense que cela dépend vraiment de votre situation. J'utilise rarement, voire jamais, i dans foreach, uniquement dans des boucles for, car je trouve que je suis trop peu descriptif dans ces cas. Pour foreach, j'essaie d'utiliser une abréviation du type d'objet en cours de bouclage. par exemple:

foreach(DataRow dr in datatable.Rows)
{
    //do stuff to/with datarow dr here
}

de toute façon, juste mon 0,02 $.

Answer 14

Si vous le nommez, cela vous aidera à décrire quelque chose qui décrit la boucle. Mais d’habitude je me sers de i.

Answer 15

Tant que vous utilisez i pour compter les boucles ou une partie d'un index allant de 0 (ou 1 en fonction de PL) à n, je dirais que tout va bien.

Sinon, il est probablement facile de nommer quelque chose de significatif, c’est plus qu’un index.

Answer 16

Je ferai remarquer que i et j sont aussi des notations mathématiques pour les indices de matrice. Et généralement, vous passez en boucle sur un tableau. C'est donc logique.

Answer 17

Tant que vous l'utilisez temporairement dans une simple boucle et que ce que vous faites est évident, bien sûr. Cela dit, n'y a-t-il pas d'autres mots que vous pouvez utiliser à la place?

i est largement connu comme un itérateur de boucle. Vous risquez donc mieux de confondre les programmeurs de maintenance si vous l'utilisez en dehors d'une boucle, mais si vous utilisez quelque chose de plus descriptif (comme filecounter ), cela rend le code plus agréable.

Answer 18

Cela dépend. Si vous parcourez un ensemble de données particulier, je pense qu'il est plus logique d'utiliser un nom descriptif. (par exemple, compteur_fichier comme suggéré par Dan).

Cependant, si vous effectuez une boucle arbitraire, alors i est acceptable. Comme me l'a décrit un collègue de travail - i est une convention qui signifie "cette variable n'est modifiée que par la construction de boucle pour . Si ce n'est pas le cas, n'utilisez pas i "

".

Answer 19

L’utilisation de i, j, k pour les compteurs de boucle INTEGER remonte aux débuts de FORTRAN.
Personnellement, je n'ai pas de problème avec eux tant qu'ils sont INTEGER count.
Mais ensuite j'ai grandi sur Fortran!

Answer 20

Mon sentiment est que le concept consistant à utiliser une seule lettre convient parfaitement à " simple " boucles, cependant, j’ai appris à utiliser les lettres doubles il y a longtemps et cela a très bien fonctionné.

J'ai posé une question similaire la semaine dernière. Les éléments suivants font partie de ma propre réponse :

// recommended style              ●    // "typical" single-letter style
                                  ●
for (ii=0; ii<10; ++ii) {         ●    for (i=0; i<10; ++i) {
    for (jj=0; jj<10; ++jj) {     ●        for (j=0; j<10; ++j) {
        mm[ii][jj] = ii * jj;     ●             m[i][j] = i * j;
    }                             ●        }
}                                 ●    }

au cas où l'avantage ne serait pas immédiatement évident: en recherchant une lettre dans le code, vous découvrirez de nombreuses choses qui ne sont pas ce que vous recherchez. la lettre i apparaît assez souvent dans le code où ce n'est pas la variable que vous recherchez.

Je le fais de cette façon depuis au moins 10 ans.

Notez que de nombreuses personnes ont indiqué que l'une ou l'autre / les deux réponses ci-dessus sont "laides" ...

Answer 21

Je vais aller à contre-courant et dire non.

Pour la foule qui dit "i est compris comme un itérateur", cela peut être vrai, mais pour moi, cela équivaut à des commentaires tels que "Attribuez la valeur 5 à la variable Y. Les noms de variables comme comment devraient expliquer pourquoi" / ce qui n'est pas le comment.

Pour utiliser un exemple tiré d'une réponse précédente:

for(int i = 0; i < 10; i++)
{
    // i is well known here to be the index
    objectCollection[i].SomeProperty = someValue;
}

Est-il beaucoup plus difficile d'utiliser un nom significatif comme celui-ci?

for(int objectCollectionIndex = 0; objectCollectionIndex  < 10; objectCollectionIndex ++)
{
    objectCollection[objectCollectionIndex].SomeProperty = someValue;
}

Attribué le nom de la variable (empruntée), objectCollection est assez mal nommé aussi.