Cómo abreviar nombres de variables [cerrado]

Siempre lucho para abreviar nombres de variables. ¿Hay algún estándar para abreviar nombres de variables?

El estándar que uso es no abreviar nombres de variables a menos que la abreviatura sea más legible que la versión completa ( ipor ejemplo, para índices de iteración). Nombramos cosas para poder comunicarnos. La abreviatura de nombres de variables generalmente solo disminuye su capacidad de comunicarse.

No soy un programador de C #, así que no puedo darle muchos consejos sobre las convenciones de C #. Pero tengo algunas ideas sobre las abreviaturas.

A medida que crecí y tuve más experiencia, me encontré abreviando cada vez menos. Admito que no era un buen mecanógrafo cuando comencé a programar. He mejorado en eso desde entonces;). Voy a abreviar libremente las variables que tienen un alcance muy limitado, de modo que pueda ver toda su vida útil en una pantalla. Pero aparte de eso, prefiero no hacerlo si puedo evitarlo; nunca abrevío para guardar la escritura.

Todavía trato de mantener mis líneas por debajo de 80 caracteres. No estoy seguro si eso tiene sentido en estos días, pero es un viejo hábito. Así que abreviaré si el nombre de una variable será muy largo. Pero antes de hacerlo, intentaré encontrar un nombre más conciso que sea igualmente claro: todo lo demás igual de más corto es mejor (hablando de la forma expandida).

Cuando abrevie, es más importante, creo, que siempre abrevie de la misma manera en una base de código determinada y en bases de código relacionadas. Es probable que su primer instinto sea el adecuado, ya que será más fácil para usted recordarlo, pero puede valer la pena consultarlo con otras personas en el mismo proyecto. En estos días trabajo principalmente con otro programador, en una oficina abierta llena de no programadores. Piensan que estamos locos, porque a menudo tenemos discusiones detalladas sobre cómo abreviar consistentemente nombres de variables relacionadas, o ordenar parámetros consistentemente en llamadas a funciones, etc. Pero nombrar es importante, incluso para dos personas. En equipos más grandes se vuelve aún más importante. Una cosa sobre la que soy bastante religioso es arreglar las inconsistencias en cosas como esta tan pronto como las descubro.

EDITAR: creo que algunas abreviaturas son buenas. En mi trabajo actual, gran parte del código que escribo tiene que ver con la evaluación de splines y otras funciones paramétricas, en ciertos valores de parámetros. Nuestra base de código es de hecho inconsistente a este respecto. Sé que u se usa en algunos lugares y param (una abreviatura en sí misma) se usa en otros. U es una abreviatura generalmente entendida para el parámetro en este dominio, por lo que creo que deberíamos pasar y hacer esto consistente. Estaría bien con cualquiera de u, param o parámetro. Los usamos tanto que es poco probable que haya alguna confusión, siempre que usemos solo uno . Pero preferiría que tú.

Sin embargo, es peor que eso: en realidad tenemos varios tipos de parámetros. Y tenemos más de un nombre para algunos de ellos: uggh.

La razón por la cual esto se volvió inconsistente es el libro de texto. Resultó que teníamos que mapear entre seis espacios de parámetros; las razones son complicadas, pero básicamente teníamos que tener parámetros que correspondieran al espacio de parámetros, espacio de parámetros normalizado, espacio de longitud de arco, espacio de longitud de arco normalizado, espacio por partes y normalizado. espacio por partes. Al principio, no nos dimos cuenta de que tendríamos que mapear de un lado a otro entre todos estos espacios. Y éramos inconsistentes en cómo nombramos los parámetros que describen los puntos en esos espacios.

Esto sucede a veces: tu aplicación crece y haces algunas cosas inconsistentes mientras la creces. Lo importante es que reconozca que se ha desordenado y entre y lo arregle antes de que el desorden infecte todo lo demás y termine con una pila de escombros.

El vry rsn no se trajo st mk sr th cd s rdbl nd mntnbl eg

int accountBalanceInSavings

-> podría abreviarse a

int accBalInSaving

Tenga en cuenta que dos de las cuatro palabras son shortend (cuenta-> acc y Balance-> Bal), pero las otras dos no lo son. La regla que se aplica aquí -abriva las primeras 2 palabras, no son "palabras de más de 6 letras", porque las de 2 7 letras eran y la otra no.

Entonces podría / debería ser 'accBalInSav', yuk yuk yuk .......

Mi experiencia como los programadores se hacen más viejos y más sabios, abrevian cada vez menos. Para mi edad, probablemente estamos tratando de compensar los pecados de nuestra juventud .....

Tenga en cuenta que el código se escribe una vez (bueno, muchos más que una vez) y se lee miles de veces.

Hay una pregunta similar sobre los nombres de caracteres únicos , Uso de caracteres individuales para nombres de variables en bucles / excepciones .

Mi respuesta entonces como ahora es mantenerlos cortos donde el alcance es pequeño. Por ejemplo, un parámetro de una función corta es más legible si es corto y ocupa menos espacio. Una variable de clase amplia debe ser muy descriptiva.

El libro clásico de Steve McConnell , Code Complete, es ideal para cosas como esta.

No creo que existan reglas oficiales o comunes para las abreviaturas. Por lo general, cada individuo desarrolla un sistema de abreviaturas y dentro de cada proyecto individual. Puede haber ciertas reglas para la política de estilo de código fuente de una compañía, pero eso también variará según la compañía.

En una nota al margen, ¿por qué abreviar en absoluto? Eso dará como resultado que solo usted comprenda lo que significan las abreviaturas. Use nombres completos y descriptivos para las variables. Eso conducirá a un código autodocumentado.

En caso de duda, explíquelo.

El punto de un nombre de variable es para que el significado del código sea más claro. A menos que la abreviatura sea muy obvia, también puede usar la más pequeña posible. Los nombres de variables y nombres de funciones son típicamente los únicos fragmentos de lenguaje humano en el código y, por lo tanto, actúan como 'puntos de referencia' para que el ojo humano encuentre porciones relevantes de código (o, en una base de código grande, herramientas como grepo ack) y también como pistas para la comprensión

Cuando la próxima persona venga a leer su código, se lo agradecerán. Esa persona bien podría ser usted en un año. Tengo un montón de código que lamento abreviar, así que hoy en día trato de evitarlo.

Está bien abreviar cuando ...

... Cuando la forma abreviada se usa en inglés hablado o escrito por algo más que las personas que trabajan en su proyecto (muchos diccionarios dan este tipo de información junto al término que definen).

var extensible_markup_language_element; // don't do this
var xml_element; // better
var element; // possible if the name of the function or the documentation make it clear you're dealing with XML and not the periodic table
docs.toString(); // most people capable of reading code know docs == documentation

... Cuando la abreviatura se refiere inequívocamente a un solo concepto y sería reconocida instantáneamente por alguien que no está familiarizado con la base de código. Incluso entonces, un comentario o documento ayuda.

var auth = user.auth;
if (auth) // If the user is authenticated?
          // If the user is authorised to do something?
          // If the authentication function exists for that user group?
          // If some setting called auth is turned on for that user?
          // If the user is the author of the document in question?
          // If the user has some authority?

var attrNames = retrieveAttrs();
if (attrNames)  // hm, attrNames sounds like an array of strings - which will be boolean true even if empty - this if looks like a bug!

const MDF // author is writing an iOS app for ordering hand-carved artisanal fibreboard so anyone familiar with the problem domain knows this has plainly nothing to do with Microsoft Database Files. Though maybe the first time it comes up in the code the author should perhaps still put its full name

... Cuando el nombre de la variable existe solo en un ámbito único o una función pequeña, y no espera que el usuario obtenga significado del nombre, use un solo carácter. En tales casos, iy json comunes.

foreach $i (1..10) { say $announcement->[$i] }

... Al escribir una interfaz (es decir, no un nombre de variable, por lo que está fuera del alcance de la pregunta, mencionada solo porque los nombres de variables y las interfaces que las configuran a menudo usan el mismo vocabulario) en cuyo caso pueden aplicarse otras reglas, por ejemplo:

some_command --transaction-message "Done" # a bit wordy - keep, but ALSO allow for convenience:
some_command --msg "Done" # might be useful
some_command -m "Done"    # if you can spare -m

... cuando su base de código necesita referirse al mismo concepto muchas veces en el mismo proyecto y cuando la abreviatura se puede definir en una guía de estilo para ese proyecto, y cuando no es ambigua. Si su proyecto no es lo suficientemente grande para una guía de estilo, entonces no es lo suficientemente grande como para que valga la pena.

No voy a proporcionar un ejemplo de código para este porque, por definición, solo funciona en un proyecto grande, pero vea también el siguiente elemento:

... Al trabajar en un proyecto establecido que ha tenido múltiples contribuyentes y una guía de estilo que exige abreviaturas. En ese caso, abrevie solo según la guía de estilo, pero esté atento a los problemas y prepárese para anotar con comentarios (como "esta es una lista de nombres de atributos como cadenas").

Los tipos deben terminar en "_t"; Definiciones de estructura sin formato en "_struct"

- https://metacpan.org/source/SHLOMIF/XML-LibXML-2.0117/HACKING.txt

Una última reflexión: si todavía tiene nombres de variables inaceptablemente largos (por ejemplo, compuestos de cuatro o más unidades semánticas como totalAfterTaxInLocalCurrency), podría ser un síntoma de que su código está tratando de hacer demasiado en un solo alcance y sus funciones deben ser refactorizadas fuera o sus variables podrían ser administradas más lógicamente en un solo objeto.

La razón por la que abreviamos las variables es para dejar de escribir variables grandes, pero al mismo tiempo, la variable abreviada debe ser lo suficientemente explícita como para que pueda comprender lo que contiene en lugar de volver a donde se declaró o instancia primero. Así por ejemplo:

int accountBalanceInSavings

-> podría abreviarse a

int accBalInSaving

---> pero abreviando a

int accBal

Definitivamente no sería una buena opción, ya que uno no sería capaz de comprender qué contiene la variable con solo mirarla.

No debe abreviar cosas por abreviar cosas, debe hacerlo para su conveniencia u otras, pero si lo desea, entonces una regla general que tengo para la abreviatura es si una palabra tiene más de cuatro o cinco letras. Lo acortaré a las tres primeras letras significativas de esa palabra, por ejemplo:

int damagePerSecond;

podría abreviarse a

int dmgPerSec;

o si lo quieres lo más corto posible,

int dps;