¿Son malos los identificadores cortos? [cerrado]

¿Son malos los identificadores cortos? ¿Cómo se correlaciona la longitud del identificador con la comprensión del código? ¿Qué otros factores (además de la comprensión del código) podrían ser considerados cuando se trata de nombrar identificadores?

Solo para tratar de mantener la calidad de las respuestas, tenga en cuenta que hay algunas investigaciones sobre el tema!

Editar

¡Curioso de que todos no piensen que la longitud es relevante o tienden a preferir identificadores más grandes, cuando ambos enlaces que proporcioné indican que los identificadores grandes son dañinos!

Enlace roto

El siguiente enlace apuntaba a una investigación sobre el tema, pero ahora está roto, no parece que tenga una copia del documento y no recuerdo qué era. Lo dejo aquí en caso de que alguien más lo resuelva.

• http://evergreen.loyola.edu/chm/www/Papers/SCP2009.pdf

La mejor "regla" que he escuchado es que las longitudes de los nombres deben ser proporcionales a la longitud del alcance de la variable. Entonces, un índice iestá bien si el cuerpo del bucle tiene unas pocas líneas de largo, pero me gusta usar algo un poco más descriptivo si llega a ser más largo que 15 líneas.

Cada variable debe tener un significado, y su nombre es parte de ese significado. Y una parte muy importante, ya que ayuda al lector a comprender para qué sirve sin profundizar en el algoritmo. i, json evidentes para ser utilizados como índices, son cortos, pero muy informativos. bntes feo closeo closeButtontiene sentido. Por lo tanto, ser corto o largo no es el criterio más importante para el nombre de la variable, debería ser significativo. El significado depende en gran medida del contexto. Por ejemplo, puede dar un nombre muy corto como nla variable de cadena local que se usa en un pequeño bloque del código, digamos 10 líneas y se refiere al nombre de una propiedad (el vvalor es otro ejemplo).

Por lo tanto , los nombres de variables deben ser informativos y no importa que sean cortos o largos .

Usaré un identificador que describa la variable, independientemente de la longitud.

Los casos de i, j y k son en sí mismos tan ubicuos que se autodescriben, automáticamente se sabe que son índices de bucle. También podría decir lo mismo para:

foreach loop (Strings s : myString)

Sin embargo, los IDE ahora proporcionan herramientas de finalización de código, por lo que el único efecto secundario negativo de identificadores muy largos y descriptivos se ha eliminado afaik.

Con mucho gusto agregaré una palabra adicional a un identificador, si es necesario para explicar el propósito de la variable.

No son tan malos como los identificadores engañosos. No me importa depurar el código en el que los identificadores son solo una letra, pero en el momento en que entran en escena diferentes convenciones de nombres, se vuelve molesto. Por ejemplo, si en algún lugar ves strPersonID, y luego en otro lugar ves s_EmployeeID, es confuso saber si son ambas cadenas y si hay alguna diferencia. Además, si las variables se copian (pmapIntString = new std::map<int,int> ) y están totalmente equivocadas, me preocuparé.

Cuando se trata de mí, agrego comentarios en el código para las variables importantes utilizadas y trato de mantener el estándar dado en la guía de desarrollo. Si no hay un estándar, entonces trato de mantener la misma convención de nomenclatura en todo el código.

Yo lucho...

Solía ​​usar siempre nombres descriptivos como identificadores, pero últimamente he usado identificadores muy cortos.

Creo que depende del contexto del código:

• Si escribe funciones complejas (algoritmos), SIEMPRE use identificadores cortos (los caracteres únicos son los mejores)
• Al escribir valores de parámetros para funciones, utilice nombres descriptivos

Supongo que depende también de qué tan denso sea el código. A veces, tener nombres en realidad dificulta la lectura.

¡A veces sin nombres es totalmente críptico!

Mi pensamiento es que no son malos en sí mismos, pero no son informativos a menos que sean muy estándar.

Entonces las variables de bucle son i, j y k son tan estándar que no hay razón para no usarlas si está creando un bucle indexado.

El otro lugar donde usaré un identificador muy corto es cuando estoy declarando una variable temporal que se saldrá del alcance en unas pocas líneas de tiempo, la variable temporal de un bucle foreach, por ejemplo. Si no se hará referencia a él en ningún otro lugar, es fácil para cualquiera que lea el código ver la declaración y seguir para qué se está utilizando. Sin embargo, si se va a usar durante más de cinco o seis líneas, buscaré darle un nombre más claro.

Más allá de eso, trato de usar identificadores de longitud informativos, particularmente a nivel de clase. Quiero un identificador que pueda leer y tener una idea de para qué sirve la variable. Si se están alargando demasiado (y a veces veo código con cuatro o cinco palabras juntas para un identificador), tiendo a considerarlo como un olor a código; si necesito tanto texto para distinguir mis variables, ¿son realmente un grupo que podría almacenarse mejor en un hashmap o una lista? ¿Podría estar creando algún tipo de objeto para modelar estos datos con mayor precisión? A veces no puede, pero un identificador muy largo es un indicador de que hay algo que vale la pena mirar aquí.

Estoy muy de acuerdo con las otras respuestas aquí, pero me gustaría señalar otro factor que creo que a menudo se pasa por alto. Un buen nombre es a menudo uno que es idiomático para el código. Esto puede ser a nivel de lenguaje, algoritmo o algunas expresiones idiomáticas internas para la base de código en cuestión. El punto es que si bien el nombre puede no significar nada para alguien que no conoce el dominio del código, aún puede ser el mejor nombre en el contexto dado.

Nombrar una variable es siempre un ejercicio para equilibrar la unicidad y la comprensión. La longitud del nombre está relacionada con ambos, de diferentes maneras. Los nombres más largos son más fáciles de hacer únicos; Los nombres de longitud media tienden a ser más comprensibles que los nombres que son demasiado cortos o demasiado largos.

Un nombre de variable muy corto sólo es útil si tiene una historia que hace que sea comprensible (por ejemplo, i, j, y kpara índices; dxpara una distancia a lo largo de un eje) o un alcance que es lo suficientemente pequeño para todas las referencias sean visibles a la vez (por ejemplo, , temp). Los peores nombres de variables en el mundo son cosas como t47. ("¿Qué significa eso y por qué es diferente det46 ?") Gracias a Dios que el estilo de denominación se desarrolló principalmente con FORTRAN, pero aquí es donde se arraiga el deseo de nombres de variables más largos.

Como mostró su artículo original, los nombres demasiado largos también son difíciles de leer, ya que pueden pasar desapercibidas diferencias internas sutiles al mirar el código. (La diferencia entre DistanceBetweenXAxisAbscissae& DistanceBetweenYAxisAbscissaees realmente difícil de detectar rápidamente).

Como NoteToSelf señaló anteriormente, los requisitos para la unicidad de un nombre dependen principalmente del alcance en el que el nombre debe ser único. El índice de un bucle de 5 líneas puede seri ; Es mejor que un índice de un registro activo que se pasa de una función a otra tenga un nombre mucho más descriptivo.

Una variable local para una función puede tener un pequeño nombre descriptivo como deltaXsin problema. Una variable delta X estática en un módulo debe tener un nombre que distinga este deltaX de otros deltaX en el mismo módulo, haciéndolo más largo. Y una variable global delta X debe hacerse única en todos los módulos y en todos los demás módulos posibles que puedan crearse, probablemente concatenando el nombre del módulo con el otro nombre descriptivo. Este es uno de los muchos problemas con los globales; Para ser útilmente únicos, los nombres deben ser lo suficientemente largos como para dificultar su lectura.

Por el contrario, creo que los identificadores largos son peores que los cortos (a menos que se trate de constantes). El uso TheVariableThatHoldsTheCapacityOfMyContainerClasshace que su código sea mucho más propenso a errores que el uso Capacity.

En y por sí mismos, los identificadores cortos no son malos. El propósito de elegir buenos nombres (cortos o largos) está en servicio para codificar la claridad. Elegir identificadores al servicio de la claridad del código es más importante que cumplir con algún requisito de longitud mínima. En general, lo que esto significa es escribir nombres significativos un poco más largos.

Una observación que he tenido a lo largo de los años y hoy es menos que hace 10 o 15 años. Los programadores que no pueden escribir son los que lucharán con uñas y dientes sobre nombres variables. Son los que tienen todos los nombres de variables de 1-3 letras.

Así que mi consejo es usar un nombre significativo como han dicho muchos comentaristas y luego aprender a escribir. He estado considerando agregar una prueba de mecanografía a las entrevistas, solo para ver dónde están las personas, pero estoy empezando a ver mucho menos a los no mecanográficos a medida que las computadoras se convierten en una parte más importante de la sociedad.

El primer documento con el que se vincula parece interesante, pero su conclusión es que no encontraron evidencia significativa a favor o en contra de la hipótesis de que las "sugerencias de base", incluidos los nombres de variables significativas, ayudan en la comprensión del código. El tiempo de permanencia de la mirada utilizado como proxy para la comprensión del código es interesante, pero no es un slam dunk.

Me temo que encontré el segundo artículo simplemente tonto. El primer problema es que los ejemplos de nombres largos que proporcionan son gratuitos y no proporcionan información adicional. Creo que todos podemos estar de acuerdo en que hacer un nombre de variable más largo solo para hacerlo más largo es estúpido. Su ejemplo de nombrar una distancia variable_entre_abscisas en lugar de dx es un hombre de paja.

Más importante aún, su experimento es una prueba de memorización simple en lugar de comprensión. Prueba la capacidad de los sujetos para completar las piezas faltantes de un nombre variable cuando se presenta en una lista sin contexto. Sí, los nombres largos son más difíciles de memorizar, pero cuando estoy codificando no memorizo ​​nombres de variables, los uso para proporcionar contexto. Supongo que podría argumentar que la dificultad de recordar una variable larga hace que el código sea más difícil de escribir, pero el código se lee con mucha más frecuencia de lo que se escribe, entonces, ¿qué actividad debe optimizarse?

Una de mis principales métricas para determinar si una línea de código es legible o no es cuánto se debe leer otro contexto de otras líneas para asegurarse realmente de que comprende lo que está haciendo la línea.

Es fácil decir que "cualquiera debería poder entender que i, j y k son variables de bucle". Y la mayoría de las veces es realmente obvio. Pero aún trato de ser humilde y profesional al respecto y asumir que es fácil cometer errores al programar. Entonces, si estoy recorriendo una matriz de Grobbles, nombraré la variable de bucle grobbleIndex. También podría aceptar i como una abreviatura de índice. Cuando usa ij yk es más difícil detectar errores como usar el índice incorrecto con la matriz incorrecta, etc. Y empeora aún más cuando tienes un circuito interno.

PD. En el momento en que escribí esta respuesta, estaba codificando algunos javascript en una mini computadora portátil de 10 "con una pantalla dividida verticalmente en vim y todavía me tomé el tiempo para nombrar mis variables de bucle rowIndex y columnIndex.

En algunas aplicaciones, una variable corta simplemente no puede explicar los datos en la variable. Corto o largo es irrelevante. El uso de una variable más larga no hace que su código sea más lento. Claro que es más esfuerzo escribir un nombre de variable largo, pero al menos la persona que lee el código 6 meses después (que puede ser usted) podrá distinguir lo que está sucediendo sin necesidad de poner rastros, suponiendo que eso sea posible.

Creo que lo ideal es que los nombres sean descriptivos a menos que ...

La idea de que los nombres pueden (tal vez deberían ser) más cortos, y por lo tanto, por lo tanto, menos descriptivos, si tienen un alcance limitado, es solo una razón para desviarse del ideal.

Personalmente, con frecuencia uso nombres cortos para un pequeño número de entidades a las que se hace referencia repetidamente. Frecuentemente llamadas subrutinas específicas de la aplicación, por ejemplo.

Nunca usaría nombres de identificador con menos de 4-5 caracteres, por ejemplo, una variable de bucle podría ser Index o jIndex o kIndex dependiendo de cuántos bucles internos necesito para lograr algo, pero para otros nombres digamos una "clave" que usaría "String LKey" o "int LKey", "L" para local si se trata de una variable de método o "F" para una variable de clase privada, todos los demás identificadores como otros mencionados anteriormente deberían explicar la razón de su existencia en su nombre, de lo contrario, el El alcance del "identificador" es inútil, ¿no?