En lo que respecta a las convenciones de nomenclatura variable, ¿los iteradores deben 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 utilizarse?¿Es una variable llamada i inaceptable?
Depende del contexto, supongo. Si recorre un conjunto de Objetos en alguna colección de , entonces, desde el contexto, debería ser bastante obvio 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 no es inmediatamente claro por el contexto qué es lo que está haciendo, o si va a realizar modificaciones en el índice que se debe utilizar un nombre de variable que es más indicativo del uso.
for(int currentRow = 0; currentRow < numRows; currentRow++)
{
for(int currentCol = 0; currentCol < numCols; currentCol++)
{
someTable[currentRow][currentCol] = someValue;
}
}
Usaría iRow e iCol, pero luego comencé con FORTRAN –
FORTRAN sigue siendo impresionante para la informática científica. Lol, los científicos se reirán de ti si mencionas otros idiomas. – Josh
Doble cualquier variable de carácter individual para hacer útil la búsqueda. ii v. i, xx v. x. – user7116
Ayuda si lo nombra algo que describa por lo que está pasando. Pero usualmente solo uso i.
i es definitivamente aceptable. No estoy seguro de qué tipo de justificación necesito hacer, pero sí la uso todo el tiempo, y otros programadores muy respetados también lo hacen.
validación social, supongo :)
Sí, de hecho, que es preferible ya que cualquier programador de la lectura de su código va a entender que es simplemente un iterador.
Siempre que use i para contar bucles, o parte de un índice que va de 0 (o 1 según PL) a n, entonces diría que estoy bien.
De lo contrario, es probable que sea fácil nombrar algo significativo que es más que un índice.
Si el "algo más semántico" es "iterador", entonces no hay ninguna razón para no usar i; es un modismo bien entendido.
"i" significa "contador de bucle" a un programador. No hay nada de malo en eso
Tiendo a usar i, j, k para bucles muy localizados (solo existen por un corto período en términos de número de líneas fuente). Para las variables que existen en un área fuente más grande, tiendo a usar nombres más detallados para poder ver para qué sirven sin volver a buscar en el código.
Por cierto, creo que la convención de nomenclatura para estos vino del lenguaje temprano de Fortran donde yo era la primera variable entera (A - H eran flotadores)?
Ese es un pequeño y interesante dato sobre la historia. Gracias. – VirtuosiMedia
como dicen "Dios es real, a menos que se declare entero" –
Aquí hay otro ejemplo de algo que es perfectamente válido:
foreach (Product p in ProductList)
{
// Do something with p
}
Absolutamente. Nadie se queja nunca de que las pruebas matemáticas que dicen "consideren una función continua, f" sean incomprensibles porque la función se llama "f" en lugar de "a_continuous_function". –
Debo señalar que iyj son también notación matemática para los índices de la matriz. Y, por lo general, estás recorriendo una matriz. Entonces tiene sentido.
Siempre y cuando lo uses temporalmente dentro de un simple bucle y es obvio lo que estás haciendo, claro. 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 en realidad son más propensos a confundir a los programadores de mantenimiento si se utiliza fuera de un bucle, pero si se utiliza algo más descriptivo (como filecounter), que hace que el código más agradable.
i es aceptable, con certeza. Sin embargo, aprendí muchísimo un semestre de un maestro de C++ que tuve y que me negó el código que no tenía un nombre descriptivo para cada variable. El simple hecho 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. Código completo tiene algunas buenas palabras sobre este mismo tema.
¿Cuál es el valor de usar i en lugar de un nombre de variable más específico? Para guardar 1 segundo o 10 segundos o quizás, tal vez, incluso 30 segundos de pensar y escribir?
¿Cuál es el costo de usar i? Tal vez nada. Tal vez el código es tan simple que usar i está bien. Pero quizás, tal vez, al utilizar forzaré a los desarrolladores que acceden a este código en el futuro a pensar por un momento "¿qué quiero decir aquí?" Tendrán que pensar: "¿es un índice, un conteo, un desplazamiento, una bandera?" Tendrán que pensar: "¿este cambio es seguro, es correcto, me iré por 1?"
Usar i ahorra tiempo y esfuerzo intelectual al escribir código, pero puede terminar costando más esfuerzo intelectual en el futuro, o incluso puede dar como resultado 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 de 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 tiene ese hábito, solo toma unos segundos escribir código con nombres significativos, pero luego tiene un código que es más fácil de leer, más fácil de leer entender, y más obviamente correcto.
Utilizo i para bucles cortos.
La razón por la que está bien es que me resulta completamente inverosímil que alguien pueda ver una declaración de tipo de iterador, con inicializador, y luego tres líneas afirman que no está claro qué representa la variable. Simplemente están fingiendo, porque han decidido que los "nombres de variable significativos" deben 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 usaría en un ámbito pequeño, me ahorra preocuparme de que pueda usar un nombre que sea engañoso, o ambiguo, o algún día será útil para otra cosa en el ámbito más amplio. La razón por la que es "i" en lugar de "q" o "contar" es solo una convención tomada de las matemáticas.
No consumo i si:
i no necesariamente tiene que ir en incrementos de 1 siempre que el incremento sea consistente y claro, y por supuesto puede detenerse antes del final del iterand, pero si alguna vez cambia de dirección, o no está modificado por una iteración del ciclo (incluido el uso diabólico de iter) ator.insertAfter() en un bucle de avance), trato de recordar usar algo diferente. Esto indica que "esto no es solo una variable de bucle trivial, por lo tanto, esto puede no ser un bucle trivial".
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 sugirió Dan).
Sin embargo, si está realizando un bucle arbitrario, entonces i es aceptable. Como un compañero de trabajo me lo describió - i es una convención que significa "esta variable es sólo alguna vez modificado por el constructo for bucle Si eso no es verdad, no utilice 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!
i está muy bien, pero algo como esto no es:
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 que los programadores para intercambiar de forma inadvertida la iy la j en el código, especialmente si tienen problemas de visión o de su tema de Windows es "perrito caliente". Esto siempre es un "olor a código" para mí, es raro cuando no se estropea.
Nunca pensé demasiado sobre por qué, pero tiendo a usar jyk para índices en matrices, pero supongo que es posible confundir iy j si tiene problemas de visión. – Cercerilla
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 ... p.
foreach(Input i in inputs)
{
Process(i);
}
creo que es completamente aceptable en situaciones de bucle. Siempre he encontrado que esto es bastante estándar y nunca me encuentro con problemas de interpretación cuando me utilizan en esta instancia. foreach-loops se vuelve un poco más complicado y creo que realmente depende de tu situación. Raramente, si alguna vez uso i en foreach, solo en bucles, ya que considero que soy demasiado poco descriptivo en estos casos. para foreach, trato de usar una abreviatura del tipo de objeto que se está enlazando. e.g:
foreach(DataRow dr in datatable.Rows)
{
//do stuff to/with datarow dr here
}
de todos modos, solo mi $ 0.02.
mi sensación es que el concepto de usar una sola letra es bueno para bucles "simples", sin embargo, aprendí a usar letras dobles hace mucho tiempo y ha funcionado muy bien.
le pregunté a un similar question la semana pasada y lo que sigue es parte de my own answer:
// 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;
} ● }
} ● }i aparece muy a menudo en el código donde no es la variable que está buscando.
lo he estado haciendo de esta manera durante al menos 10 años.
nota de que mucha gente ha comentado que, o bien/los dos anteriores son "feos" ...
Y para personas con editores que pueden buscar saltos de palabra, completamente inútiles. –
Offtopic un poco: ¿por qué preincrementa la variable de bucle en la instrucción for? Normalmente veo ** POSTINCREMENT ** en lugar de preincrement. –
eficiencia. proviene de mi experiencia inicial con el lenguaje C cuando los optimizadores de ensamblaje no eran perfectos. si realiza un incremento posterior, primero se evalúan las expresiones, luego se incrementan y luego se evalúan nuevamente. si realiza un incremento previo, no hay una evaluación inicial, simplemente se incrementa y luego se evalúa. –
voy a ir contra la corriente y decir no.
Para la multitud que dice "me entienden como un iterador", eso puede ser cierto, pero para mí es el equivalente a comentarios como 'Asignar el valor 5 a la variable Y. Los nombres de variables como comentario deberían explicar el porqué/qué no 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 de usar sólo un nombre significativo como tal?
for(int objectCollectionIndex = 0; objectCollectionIndex < 10; objectCollectionIndex ++)
{
objectCollection[objectCollectionIndex].SomeProperty = someValue;
}
Concedido el nombre de la variable (prestado) objectCollection está mal nombrado también.
Solo en proyectos de equipo. Porque no hay yo en el equipo! –
Eche un vistazo a, que aborda esta cuestión. –