¿Es una variable llamada i inaceptable? [cerrado]

https://stackoverflow.com/questions/130775

02-07-2019
|

Pregunta

En lo que respecta a las convenciones de nomenclatura variable, ¿los iteradores deberían llamarse i o algo más semántico como count ? Si no usa i , ¿por qué no? Si cree que i es aceptable, ¿hay casos de iteración en los que no debería usarse?

Solución

Depende del contexto, supongo. Si estabas recorriendo un conjunto de objetos en alguna colección, entonces debería ser bastante obvio desde el contexto lo que está haciendo.

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

Sin embargo, si el contexto no aclara de inmediato qué está haciendo o si está realizando modificaciones en el índice, debe usar un nombre de variable que sea más indicativo del uso.

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

Otros consejos

" i " significa " contador de bucle " a un programador. No tiene nada de malo.

Aquí hay otro ejemplo de algo que está perfectamente bien:

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

Tiendo a usar i, j, k para bucles muy localizados (solo existen por un período corto en términos de número de líneas de origen). Para las variables que existen en un área de origen más grande, tiendo a usar nombres más detallados para poder ver para qué sirven sin buscar en el código.

Por cierto, ¿creo que la convención de nomenclatura para estos vino del lenguaje Fortran temprano donde yo era la primera variable entera (A - H eran flotantes)?

i es aceptable, por cierto. Sin embargo, aprendí una gran cantidad un semestre de un maestro de C ++ que rechazó el código que no tenía un nombre descriptivo para cada variable. El simple acto de nombrar todo descriptivamente me obligó a pensar más en mi código, y escribí mejores programas después de ese curso, no aprendiendo C ++, sino aprendiendo a nombrar todo. Code Complete tiene algunas buenas palabras sobre este mismo tema.

i está bien, pero algo así no:

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

Muy común para los programadores intercambiar inadvertidamente la i y la j en el código, especialmente si tienen mala vista o si su tema de Windows es "hotdog". Este siempre es un "código de olor" para mí, es raro que esto no se arruine.

i es tan común que es aceptable, incluso para las personas que aman los nombres de variables descriptivas.

Lo que es absolutamente inaceptable (y un pecado en mi libro) es usar i, j o ??k en cualquier otro contexto que no sea un índice entero en un bucle ... por ejemplo,

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

}

i es definitivamente aceptable. No estoy seguro de qué tipo de justificación debo hacer, pero lo uso todo el tiempo, y otros programadores muy respetados también lo hacen.

Validación social, supongo :)

Sí, de hecho es preferible ya que cualquier programador que lea su código entenderá que es simplemente un iterador.

¿Cuál es el valor de usar i en lugar de un nombre de variable más específico? ¿Para ahorrar 1 segundo o 10 segundos o tal vez, tal vez, incluso 30 segundos de pensar y escribir?

¿Cuál es el costo de usar i? Quizás nada. Tal vez el código es tan simple que usar i está bien. Pero tal vez, tal vez, usar forzaré a los desarrolladores que vengan a este código en el futuro a tener que pensar por un momento "¿qué quiero decir aquí?" Tendrán que pensar: "¿es un índice, un recuento, un desplazamiento, una bandera?" Tendrán que pensar: "¿es seguro este cambio? ¿Es correcto? ¿Me iré antes de 1?"

El uso de i ahorra tiempo y esfuerzo intelectual al escribir código, pero puede terminar costando un mayor esfuerzo intelectual en el futuro, o tal vez incluso ocasionar la introducción inadvertida de defectos debido a un malentendido del código.

En términos generales, la mayoría del desarrollo de software es mantenimiento y extensión, por lo que la cantidad de tiempo dedicado a leer su código excederá ampliamente la cantidad de tiempo dedicado a escribirlo.

Es muy fácil desarrollar el hábito de usar nombres significativos en todas partes, y una vez que tienes ese hábito, solo lleva unos segundos más escribir código con nombres significativos, pero luego tienes un código que es más fácil de leer, más fácil de entender , y más obviamente correcto.

Yo uso i para bucles cortos.

La razón por la que está bien es que me parece completamente inverosímil que alguien pueda ver una declaración de tipo iterador, con inicializador, y luego tres líneas más tarde afirman que no está claro qué representa la variable. Simplemente están fingiendo, porque han decidido que "nombres de variables significativas" debe significar " nombres largos de variables " ;.

La razón por la que realmente lo hago, es que encuentro que usar algo no relacionado con la tarea específica en cuestión, y que solo lo usaría en un ámbito pequeño, me ahorra la preocupación de que pueda usar un nombre que sea engañoso, o ambiguo, o algún día será útil para algo más en el ámbito más amplio. La razón es '' i '' en lugar de " q " o "contar" es solo una convención prestada de las matemáticas.

No uso i si:

El cuerpo del bucle no es pequeño, o
el iterador hace otra cosa que avanzar (o retirarse) desde el inicio de un rango hasta el final del ciclo:

i no necesariamente tiene que ir en incrementos de 1 siempre que el incremento sea consistente y claro, y por supuesto podría detenerse antes del final del iterand, pero si alguna vez cambia de dirección, o no se modifica por una iteración del bucle (incluido el uso diabólico de iterator.insertAfter () en un bucle de reenvío), trato de recordar usar algo diferente. Esto indica "no es solo una variable de bucle trivial, por lo tanto, puede no ser un bucle trivial".

Si el " algo más semántico " es " iterador " entonces no hay razón para no usar i; es un idioma bien entendido.

creo que es completamente aceptable en situaciones for-loop. Siempre he encontrado que esto es bastante estándar y nunca me encuentro con problemas de interpretación cuando se usa en esta instancia. los bucles foreach se vuelven un poco más complicados y creo que realmente depende de tu situación. Raramente, si alguna vez uso i en foreach, solo en for loops, ya que encuentro que no soy muy descriptivo en estos casos. para foreach trato de usar una abreviatura del tipo de objeto que se está enlazando. por ejemplo:

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

de todos modos, solo mis $ 0.02.

Ayuda si lo nombras algo que describa lo que está pasando. Pero generalmente solo uso i.

Mientras esté usando i para contar bucles, o parte de un índice que va de 0 (o 1 dependiendo de PL) a n, entonces diría que estoy bien.

De lo contrario, probablemente sea fácil nombrarlo, algo significativo es más que un simple índice.

Debo señalar que i y j también son notación matemática para índices de matriz. Y por lo general, estás recorriendo una matriz. Entonces tiene sentido.

Mientras lo estés usando temporalmente dentro de un bucle simple y sea obvio lo que estás haciendo, seguro. Dicho esto, ¿no hay otra palabra corta que puedas usar en su lugar?

i es ampliamente conocido como un iterador de bucle, por lo que es más probable que confunda a los programadores de mantenimiento si lo usa fuera de un bucle, pero si usa algo más descriptivo (como filecounter ), hace que el código sea más agradable.

Depende. Si está iterando sobre un conjunto particular de datos, entonces creo que tiene más sentido usar un nombre descriptivo. (por ejemplo, filecounter como Dan sugirió).

Sin embargo, si está realizando un ciclo arbitrario, entonces i es aceptable. Como me lo describió un compañero de trabajo: i es una convención que significa que esta variable solo se modifica mediante la construcción del bucle for . Si eso no es cierto, no use i "

El uso de i, j, k para los contadores de bucle INTEGER se remonta a los primeros días de FORTRAN.
Personalmente, no tengo ningún problema con ellos, siempre que sean cuentas INTEGER.
¡Pero luego crecí en FORTRAN!

mi sensación es que el concepto de usar una sola letra está bien para "simple" bucles, sin embargo, aprendí a usar letras dobles hace mucho tiempo y ha funcionado muy bien.

Hice una pregunta similar la semana pasada y lo siguiente es parte de mi propia respuesta :

// 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;
    }                             ●        }
}                                 ●    }

en caso de que el beneficio no sea obvio de inmediato: al buscar en el código cualquier letra, encontrará muchas cosas que no son lo que está buscando. la letra i aparece con bastante frecuencia en el código donde no es la variable que está buscando.

Lo he estado haciendo así durante al menos 10 años.

tenga en cuenta que muchas personas comentaron que cualquiera / ambos de los anteriores son "feos" ...

Voy a ir contra la corriente y decir no.

Para la multitud que dice '' se entiende como un iterador '', eso puede ser cierto, pero para mí eso es el equivalente de comentarios como 'Asignar el valor 5 a la variable Y. Los nombres de variables como el comentario deberían explicar por qué / qué no el cómo.

Para usar un ejemplo de una respuesta anterior:

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

¿Es mucho más difícil usar un nombre significativo como este?

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

Por supuesto, el nombre de la variable (prestada) objectCollection también tiene un nombre bastante malo.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow