Uso de caracteres únicos para nombres de variables en bucles / excepciones [duplicado]

Estoy totalmente de acuerdo con tu opinión, y creo que no es todo que subjetivo.

El nombre de una variable es tan relevante como su alcance.

No tiene sentido en discusiones interminables sobre el nombre de una variable que solo será leída por una persona que lea ese fragmento de código pequeño en particular. Por otro lado, los nombres de las clases y los miembros deben indicar claramente lo que está sucediendo. Gran parte del comportamiento esperado debe explicarse en un nombre conciso.

Las convenciones mejoran la legibilidad.

i y e son convenciones comunes que se usan para esas pequeñas variables de alcance. Su intención es muy clara si conoces la convención.

La concisión mejora la legibilidad.

Un nombre de variable corto que represente claramente su intención debe preferirse a un nombre de variable grande.

Esto realmente depende de la situación / contexto (y no hay una solución para todos ).

En general, i, j, k [btw, i se pueden tomar como índice ; su uso proviene de los antecedentes matemáticos, donde esos fueron los tres primeros índices (recuerde el cálculo del tensor). También puede estar conectado a la historia de Fortran, donde i es el primer número entero implícitamente escrito, a menudo se usaba como un índice de un bucle. ] se utilizan a menudo si es un contador simple. Si tiene un significado específico, como mes o año , más largo es el nombre de la variable.

Estoy de acuerdo contigo: i como nombre de variable de bucle es un lenguaje antiguo que no debe confundir a nadie. Igual que e para una variable de excepción en un bloque catch. El último (o más bien ambos) debe ser corto y simple, reduciendo el alcance de la variable, limitando la posibilidad de confusión para los lectores. Y si alguien quiere buscar excepciones, de todos modos es mejor buscar tipos de excepción o bloques de captura.

Dicho esto, personalmente prefiero usar nombres de variables de bucle más largos, como index o idx . Mi razón es que i es tan corto que es difícil ubicarlo con el cursor.

Actualizar

Para referencia, los argumentos de su compañero de trabajo probablemente provienen de Reglas de Ottinger's para nombrar : un enfoque excelente y pragmático A la asignatura, recomendado para su lectura. Sin embargo, puede haber pasado por alto las partes citadas a continuación:

  

Mi preferencia personal es que los nombres de una sola letra SOLO pueden usarse como variables locales dentro de los métodos cortos . La longitud de un nombre debe corresponder de alguna manera al tamaño de su alcance. Si se puede ver o usar una variable o una constante en varios lugares en un cuerpo de código, es imperativo darle un nombre fácil de buscar.

Y

  

Ciertamente, un contador de bucle puede llamarse i o j o k (¡aunque nunca es l !) si su alcance es muy, muy pequeño y ningún otro nombre puede entrar en conflicto con él. Estos son permitidos porque son nombres de dominio de soluciones tradicionales.

los nombres más detallados pueden ser igualmente sin sentido. "i" se usa tan comúnmente como un contador de iteración simple, es una práctica casi estándar. Llamar al mismo contador "iter" porque algunos "estándares de codificación" prohíben que los nombres de las variables de una sola letra no agreguen ningún valor.

"x", "y" y "z" son nombres de coordenadas estándar, llamándolos xCoord, yCoord, zCoord no agrega nada.

"e", por supuesto, es una expresión matemática. Pero es relativamente común usarlo como un nombre para las excepciones en los bloques catch en Java. Llamarlo "exc" o algo similar no volvería a agregar valor real.

Prefiero nombres de variables significativos, incluso para variables de bucle. Por lo tanto, generalmente escribo algo como

for (int vertexIndex=0; vertexIndex<polygon.VertexCount; vertexIndex++)
   DoSomethingWithVertex(polygon[vertexIndex]);

Me doy cuenta de que hay poca diferencia (de cualquier manera) para un bucle pequeño como este, pero:

• si el cuerpo del bucle es más largo, vertexIndex suele ser más claro que i . Por supuesto, i es un índice, pero ¿qué índice? ¿A qué matriz? ¿A qué elemento de esa matriz?
• si el cuerpo del bucle llama a otras funciones y pasa el índice como un argumento, a menudo es más fácil nombrar el valor de manera consistente en la ubicación del llamante y el destinatario, y no querrá llamar a los parámetros del método i y x
• si hay bucles anidados, el uso de i , j , k como índices es muy confuso y propenso a errores

para ser coherente, solo uso nombres de variables significativos para los índices de bucles en todas partes.

@ André Paramés preguntó: "Si el cuerpo del bucle es lo suficientemente largo como para ocultar el significado de i, ¿no es hora de refactorizar?"

Un cerebro humano típico tiene una capacidad de memoria a corto plazo de aproximadamente 7 fragmentos de datos. Entonces, si el cuerpo del bucle contiene 8 o más fragmentos (donde "fragmentos" son declaraciones, variables locales, parámetros, comentarios), entonces su cerebro no puede almacenar el significado de cada uno de esos fragmentos simultáneamente. En su lugar, su cerebro cambiará partes dentro y fuera de la memoria de trabajo mientras lee el código. Por ejemplo, si usa nombres de variables como i y j , su cerebro cambiará los significados de i y j de su memoria de trabajo; la próxima vez que lea j , su cerebro usualmente se basará en el contexto para encontrar el significado, es decir, si lee customers[j] en la mitad del cuerpo del bucle, su cerebro inferirá que j es un índice en la matriz customers . Si hubiera escrito customers[vertexIndex] , vería que está usando el índice incorrecto. Y eso es para cuerpos de bucles muy cortos con solo 8 fragmentos de información, es decir, 5-8 líneas de código.

Si el cuerpo se alarga, normalmente lo extraerías en una función separada con un parámetro vertexIndex . Y ese es el segundo punto que comentaba: si la variable se llama vertexIndex dentro de esa función, también debería llamarse vertexIndex en la persona que llama.

No estoy de acuerdo con los puntos de tus colegas.

Para mí, significa "iteración". Bastante significativo en el caso de un bucle.

La mayoría de los IDE permiten la búsqueda de expresiones regulares a través del texto. Así que puedes buscar 'e' no dentro de una palabra. Eso sería efectivo.

(Esto está centrado en .NET pero su pregunta mencionó las expresiones C # lambda, por lo que creo que esto es relevante en su caso).

Siempre usaría ex para una excepción, ya que e ya está siendo usado (por las convenciones de WinForms y ASP.NET WebForms) como el argumento EventArgs -typed para un controlador de eventos.

por ejemplo

protected void button_Click(object sender, System.EventArgs e)
{
    try
    {
        // whatever
    }
    catch (Exception ex)
    {
        // some exception handling
    }
}

Sin embargo, MSDN utiliza e para variables de excepción .

Durante esta discusión, sugeriría tener en cuenta dos cosas:

• Las convenciones de nomenclatura de variables generalmente pueden considerarse una forma de guerra religiosa .
• La convención de codificación más importante es mantener el estilo del código existente .

No veo ninguna pregunta aquí, pero "i", "j" por lo general se refieren a coordenadas como "x" y "y" (mi preferencia personal), entiendo que "e" podría ser una característica demasiado común pero si busca excepciones, vaya a esa búsqueda "Excepción".

el mayor problema de usar variables de una sola letra es que puede confundirse con ellas, pero si esa variable tiene un alcance limitado, como en un bucle o en un catch catch, no veo ningún problema con ella

Por lo general, no es muy relevante cuando tiene un solo bucle, y prefiero usar i o j por simplicidad (y debido a la convención). Con el bucle anidado, a veces uso nombres más detallados para reconocer qué índice se relaciona con qué. Por ejemplo, si tengo dos matrices: de fechas y cantidades, y tengo un bucle anidado iterando primero sobre fechas, y luego sobre cantidades, usaría los nombres dateIdx y quantityIdx, para evitar confusiones. He tenido errores en mi código cuando escribí

matrix[i][j] = fun(dates[i], quantities[j]);

pero debería tener

matrix[i][j] = fun(dates[j], quantities[i]);

Con nombres más detallados, fácilmente detectaría el error, ya que

matrix[quantityIdx][dateIdx] = fun(dates[quantityIdx], quantities[dateIdx]);

se vería mal.

Los nombres de variables cortos son como los pronombres en lenguajes naturales: para ser usados en un contexto / ámbito pequeño. "i" en un bucle corto (sin anidamientos) o "e" en una secuencia de algunas capturas están perfectamente bien. En muchos casos, el nombre largo / descriptivo para "i" sería "the_stupid_index_needed_to_get_at_the_really_interesting_things" y usas una expresión lambda solo porque se necesita en un contexto.

Perl's $ _ es un súper pronombre que funciona (para programadores de Perl); a pesar de que se me permita / aliente omitir incluso 'it' (solo "imprimir" para "imprimir $ _") es algo que temo.

La búsqueda de nombres de variables para detectar problemas en el código no sería mi primera idea. Creo que el programador debería tener una idea acerca de la clase o función donde buscar en caso de problemas específicos.

Una pregunta epistemológica interesante es la de significado . Tu colega parece asumir que solo porque algo significa algo para él , entonces tiene significado y, de lo contrario, no lo es.

La verdad es, por supuesto, que todos esos símbolos que utilizamos todos los días, no solo en programación, tienen significado solo porque se los atribuimos. O, para decirlo de otra manera, el significado está en su cerebro, no en el símbolo. (Para aclarar esto a los doce, piense en una tableta cuneiforme: seguramente alguna vez tuvo un significado para los escritores, sin embargo, para la mayoría de los miles de millones de personas de hoy no lo tiene).

A la luz de esto, la suposición de que los nombres largos significan algo, mientras que los nombres cortos no lo hacen, es absurda. Además, la expectativa de que un nombre largo en el texto de un programa de alguna manera tenga el significado que posiblemente tenga en un contexto diferente puede generar confusión.

Algunos puntos:

• He escuchado que sugiere que prefieras usar "ii" a "i" porque si alguna vez tienes que buscar tu índice de bucle, podrás hacerlo (y es más distintivo en términos visuales en general) ), y creo que es una buena idea.
• Depende del alcance y el contenido de su bucle. Si su bucle simplemente está haciendo algo 10 veces (por ejemplo, si ni siquiera tiene acceso a la variable de bucle), entonces creo que "i" o "ii" es mil veces más razonable que un nombre más largo. Todo aquel que haya programado algo debe saber o aprender que "i" normalmente significa "variable de bucle"
• Si su bucle tiene un gran bloque de código interno, considere extraerlo de una función, pero de cualquier forma, puede ser valioso tener un corto pero un nombre significativo, por ejemplo. carIdx o día, no solo porque puede usar "i" dentro del cuerpo del bucle.
• Si su bucle recorre el contenido de una estructura de datos, use un nombre relevante: una abreviatura o minúscula del tipo de datos o variable contenida si es razonablemente distintiva (por ejemplo, forfor car in cars cars) o una forma más larga si tu bucle es más complejo.
• Creo que lo mismo se aplica a las lambdas y las excepciones, aunque estoy menos familiarizado. Por ejemplo, si hay un nombre razonable para la entrada de su lambda, especialmente si hay más de uno, entonces utilícelo, pero la mayoría de las veces, todo el PUNTO de una lambda es tomar una entrada anónima, que todos entienden " x "significa muy bien.

Cuando se habla de código legible, debe tener en cuenta algunas cosas:

• ¿Cuáles son tus estándares de codificación?
• ¿Cuáles son las convenciones comunes para su plataforma?
• ¿Existe la posibilidad de confusión?

Suponiendo que sus estándares de codificación no dicen mucho sobre las convenciones de nomenclatura de variables, debería pensar en discutir el código. Por ejemplo, con el siguiente bucle:

for(int i = 0; i < 10; i++)
{
    function(i);
}

El bucle y todas sus funciones se pueden ver claramente para la totalidad de su alcance. Ahora, imagine que tenemos bucles anidados (mi favorito es el bucle dentro de un bucle dentro de un bucle); O tal vez un bucle que abarca 100 líneas. En ese momento, los iteradores de una sola letra no tienen mucho sentido, porque es muy fácil perderse en el alcance. Es posible que desee refactorizar esas 100 líneas de código en algunos métodos / funciones para controlarlo un poco, pero asigne un nombre significativo al índice.

Sobre el tema de las excepciones, tiendo a estar de acuerdo en que e simplemente no es un buen nombre. Sin embargo, mis razones son diferentes a las de tu amigo. He hecho mucha programación en Java a lo largo de los años, y tengo que lidiar con todas esas desagradables excepciones comprobadas que nunca serán lanzadas a menos que alguien hackee su instalación de Java. Es un hecho de la vida. Entonces, como está manejando una excepción, tiene que encapsular parte de su manejo de excepciones dentro de otro controlador de excepciones. Un lugar común en que esto ocurre es con el código JDBC.

Línea inferior, ya que cada excepción que estaba verificando necesita un nombre único, y está manejando varios tipos de errores en una cláusula de prueba, dé a esas excepciones nombres que signifiquen algo. Ver e , e1 , e2 no ayuda cuando estoy leyendo el código. ¿Qué tipo de excepción estoy viendo? Así que de nuevo, ya que hay espacio para la confusión, use nombres largos.

Uso i como contador en bucles solo cuando:

• se utiliza como un índice; y
• cuando su alcance es muy corto.

Como dijo Rook, el término i tiene una base matemática como índice que se etiqueta como una convención de programación. Sin embargo, si es un bucle largo, que contiene muchas variables, cambiaría el nombre del contador i a algo más explícito. Si tiene bucles anidados que se repiten por ejemplo, por ejemplo, en una matriz, generalmente uso row y col en lugar de que i y j no estén claramente claros de a qué se refieren ("¿Fue A[i][j] o A[j][i] ...? ").

Con respecto a e para excepciones, tiendo a usar ex porque he visto que e se usa para element .

Se trata de la diferencia entre "¿Qué estás haciendo?" vs. "¿Cómo lo estás haciendo?"

En primer lugar, cuando sea posible, use un foreach en lugar de un for . Expresa mejor lo que estás haciendo (es decir, recorre la colección y procesa cada elemento). Esto elimina el problema de nombrar por completo.

Si la variable de índice tiene otro significado que no sea "the_stupid_index_needed_to_get_at_the_really_interesting_things" (gracias E.H.) luego use ese significado. row y col deben preferirse a i y j si la matriz representa una tabla. También me gusta usar position o pos si estoy haciendo mucho intercambio.

Sin embargo, el idioma for (int i = 0 ....) está tan bien establecido, que es el estándar de facto para una iteración. No te metas con un lenguaje bien establecido sin una buena razón.

Excepción a las anteriores: Matemáticas o Física: use las fórmulas estándar del texto.

v = d/t; es más familiar para un físico o ingeniero que velocity = distance / time;

Aunque no tengo problemas con el uso de "i", los estándares de conding exigen algo más. No perdería el tiempo discutiendo si es necesario. Para mí, "loopIndex" y "loopCounter" son dos nombres estándar que uso en lugar de "i".

@ nikie ya enumeró algunos de mis argumentos, pero quiero agregar que tu argumento para limitar la verbosidad es débil.

Mirando el código de forma aislada, un nombre más descriptivo ayudaría. Identificar el bucle en sí no es un problema como mencionaste.

Utilizará la 'i' muchas veces en una aplicación y podría ahorrar algo de escritura, pero no todas se refieren a la misma cosa. Muchos scripts de SQL son alias de una tabla con una sola letra, pero cada vez que se usa, se refiere a la misma tabla.

Crear nombres significativos puede ser difícil, por lo que es mejor convertirlo en un hábito.

Pensé que i significaba 'incremento'. Creo que la gran cantidad de respuestas diferentes indica que hay algo en la pregunta original sobre el significado de los nombres de las variables: a menudo significan algo tradicional, pero muchas personas las usan sin saber qué es la tradición. Es fácil decir que alguien que no sabe qué significa i "no debería ser un programador", pero ¿cómo aprendes qué significa i ? Hay media docena de respuestas aquí.

Steve McConnell en Code Complete tenía un gran consejo para la precisión de los nombres de las variables, todo depende del alcance y uso de la variable. Si tiene una clase grande, es mejor que las variables miembro tengan nombres claros, ya que quiere saber qué representa la variable cuando está enterrado en el código a mitad del archivo. Si tiene una función corta o una variable que solo se usa para unas pocas líneas de código, puede hacerla tan breve como desee ya que no se va a confundir acerca de dónde está definido o qué representa, y un nombre más pequeño hace que el código más claro.

Por lo tanto, para su caso, i, e y x son grandes nombres de variables. (asumiendo que, por supuesto, no tiene grandes bucles complejos)

Para "e" , que por supuesto significa "excepción" o "error", es fácil buscar excepciones, solo debes asegurarte de que tu búsqueda coincida con palabras completas (también podría buscar "e)" con haciendo coincidir palabras completas, si no usa un espacio entre la variable y el paréntesis, no encontrará muchas "e" por sí mismas, excepto en los controladores de excepciones.

Para "i" , tiene un significado: significa "iterador" (o posiblemente "índice" o "incrementador").

Hay otra razón para tener un nombre de variable corto: atajos a lo que serían nombres de variable / clase más largos que se usan muy a menudo en un marco o lo que sea. Como el JQuery "$" .