variables - all_products - ¿Es una variable llamada i inaceptable?

shopify liquid operators (21)

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

"i" significa "contador de bucle" para un programador. No hay nada de malo en eso

¿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?"

El uso de i ahorra tiempo y esfuerzo intelectual al escribir el 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 tienes ese hábito, solo necesitas unos segundos más para escribir el código con nombres significativos, pero luego tienes un código que es más fácil de leer, comprender y más. obviamente correcto.

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

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

Ayuda si lo nombra algo que describa por lo que está pasando. Pero usualmente solo uso i.

Creo que soy completamente aceptable en situaciones de bucle for. 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. p.ej:

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

de todos modos, solo mi $ 0.02.

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.

Depende del contexto, supongo. Si recorre 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 no está inmediatamente claro del contexto qué es lo que está haciendo, o si está haciendo 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; } }

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 es aceptable. Como me lo describió un compañero de trabajo, es una convención que significa que "esta variable solo se modificará por el constructo de bucle for . Si eso no es cierto, no lo use".

El uso de i, j, k para los contadores de bucles 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!

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 ciclo ... por ejemplo

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

Mientras 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?

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

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

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

Siempre que estés 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 nombrar algo significativo, es más que solo un índice.

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 carrozas).

Yo uso i para bucles cortos.

La razón por la que está bien es que considero totalmente 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 porque me parece que el uso de algo que no está 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 uso i si:

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

No necesariamente tengo 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 ciclo (incluido el uso diabólico de iterator.insertAfter () en un bucle de avance), intento 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".

estoy 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 para los programadores intercambiar inadvertidamente el i y el j en el código, especialmente si tienen mala vista o su tema de Windows es "hotdog". Esto siempre es un "olor a código" para mí, es raro cuando no se estropea.

yo definitivamente soy 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 :)

i soy aceptable, por cierto. Sin embargo, aprendí muchísimo un semestre de un profesor 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. Code Complete tiene algunas buenas palabras sobre este mismo tema.

Voy a ir contra corriente y decir que 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 el comentario deben explicar el 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 ese?

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

De acuerdo, el nombre de variable (prestado) objectCollection también está mal nombrado.

mi impresión es que el concepto de usar una sola letra está bien para los bucles "simples", sin embargo, aprendí a usar letras dobles hace mucho tiempo y me salió muy bien.

Hice una pregunta similar la semana pasada y la 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 inmediatamente obvio: al buscar en el código una sola 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 de esta manera durante al menos 10 años.

tenga en cuenta que muchas personas comentaron que cualquiera de las dos cosas anteriores es "fea" ...