Convención de nombres (programación)

En programación informática , una convención de nomenclatura es un conjunto de reglas para elegir la secuencia de caracteres que se utilizará para los identificadores que denotan variables , tipos , funciones y otras entidades en el código fuente y la documentación .

Las razones para utilizar una convención de nombres (en lugar de permitir que los programadores elijan cualquier secuencia de caracteres) incluyen las siguientes:

• Para reducir el esfuerzo necesario para leer y comprender el código fuente ; ^[1]
• Permitir que las revisiones de código se centren en cuestiones más importantes que la sintaxis y los estándares de nombres.
• Permitir que las herramientas de revisión de la calidad del código centren sus informes principalmente en cuestiones significativas distintas de las preferencias de sintaxis y estilo.

La elección de las convenciones de nomenclatura puede ser un tema controvertido, ya que los partidarios de cada una de ellas sostienen que las suyas son las mejores y las demás, inferiores. En el lenguaje coloquial, se dice que esto es una cuestión de dogma . ^[2] Muchas empresas también han establecido su propio conjunto de convenciones.

Los beneficios de una convención de nomenclatura pueden incluir lo siguiente:

• para proporcionar información adicional (es decir, metadatos ) sobre el uso que se le da a un identificador;
• para ayudar a formalizar las expectativas y promover la coherencia dentro de un equipo de desarrollo;
• permitir el uso de herramientas de refactorización automatizada o de búsqueda y reemplazo con un potencial mínimo de error;
• para mejorar la claridad en casos de posible ambigüedad;
• para mejorar la apariencia estética y profesional del producto de trabajo (por ejemplo, no permitiendo nombres demasiado largos, nombres cómicos o "lindos" o abreviaturas);
• para ayudar a evitar "colisiones de nombres" que podrían ocurrir cuando se combina el producto del trabajo de diferentes organizaciones (ver también: espacios de nombres );
• proporcionar datos significativos para ser utilizados en las entregas de proyectos que requieren la presentación del código fuente del programa y toda la documentación relevante;
• para proporcionar una mejor comprensión en caso de reutilización de código después de un largo intervalo de tiempo.

La elección de las convenciones de nomenclatura (y el grado en que se aplican) suele ser un tema polémico, ya que algunos sostienen que su punto de vista es el mejor y otros, inferiores. Además, incluso con convenciones de nomenclatura bien definidas, algunas organizaciones pueden no adherirse a ellas de manera consistente, lo que causa inconsistencia y confusión. Estos desafíos pueden verse exacerbados si las reglas de las convenciones de nomenclatura son internamente inconsistentes, arbitrarias, difíciles de recordar o se perciben como más onerosas que beneficiosas.

Los identificadores bien elegidos hacen que sea mucho más fácil para los desarrolladores y analistas comprender qué está haciendo el sistema y cómo corregir o ampliar el código fuente para satisfacer nuevas necesidades.

Por ejemplo, aunque

 a = b * c ;    

es sintácticamente correcto, su propósito no es evidente. Compárese esto con:

 pago_semanal = horas_trabajadas * tarifa_de_pago_por_hora ;    

lo que implica la intención y el significado del código fuente, al menos para aquellos familiarizados con el contexto de la declaración.

Los experimentos sugieren que el estilo del identificador afecta el recuerdo y la precisión y que la familiaridad con un estilo acelera el recuerdo. ^[3]

Esta sección no cita ninguna fuente . Por favor, ayude a mejorar esta sección añadiendo citas de fuentes fiables . El material sin fuentes puede ser cuestionado y eliminado . ( Septiembre de 2010 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Las reglas exactas de una convención de nomenclatura dependen del contexto en el que se emplean. No obstante, existen varios elementos comunes que influyen en la mayoría de las convenciones de nomenclatura de uso común en la actualidad, si no en todas.

Los elementos fundamentales de todas las convenciones de nomenclatura son las reglas relacionadas con la longitud del identificador (es decir, la cantidad finita de caracteres individuales permitidos en un identificador). Algunas reglas dictan un límite numérico fijo, mientras que otras especifican heurísticas o pautas menos precisas.

Las reglas de longitud de los identificadores suelen ser objeto de controversia en la práctica y de mucho debate académico.

Algunas consideraciones:

• Se pueden preferir identificadores más cortos por ser más convenientes, porque son más fáciles de escribir (aunque muchos IDE y editores de texto proporcionan la función de completar texto, lo que mitiga este problema)
• Los identificadores extremadamente cortos (como 'i' o 'j') son muy difíciles de distinguir de forma única utilizando herramientas de búsqueda y reemplazo automatizadas (aunque esto no es un problema para las herramientas basadas en expresiones regulares )
• Se pueden preferir identificadores más largos porque los identificadores cortos no pueden codificar suficiente información o parecen demasiado crípticos.
• Los identificadores más largos pueden no ser utilizados debido al desorden visual.

Es una cuestión de investigación abierta si algunos programadores prefieren identificadores más cortos porque son más fáciles de escribir o idear que identificadores más largos, o porque en muchas situaciones un identificador más largo simplemente satura el código visible y no proporciona ningún beneficio adicional percibido.

La brevedad en la programación podría atribuirse en parte a:

• Los primeros enlazadores requerían que los nombres de las variables se limitaran a 6 caracteres para ahorrar memoria. Un "avance" posterior permitió que se utilizaran nombres de variables más largos para facilitar la comprensión humana, pero donde solo los primeros caracteres eran importantes. En algunas versiones de BASIC, como TRS-80 Nivel 2 Basic, se permitían nombres largos, pero solo las dos primeras letras eran importantes. Esta característica permitía un comportamiento erróneo que podía ser difícil de depurar, por ejemplo, cuando se utilizaban nombres como "VALOR" e "IVA" y se pretendía que fueran distintos.
• Los primeros editores de código fuente carecían de función de autocompletado
• Los primeros monitores de baja resolución con longitud de línea limitada (por ejemplo, solo 80 caracteres)
• Gran parte de la informática tiene su origen en las matemáticas, donde los nombres de las variables tradicionalmente son solo una letra.

Algunas convenciones de nomenclatura limitan si las letras pueden aparecer en mayúsculas o minúsculas. Otras convenciones no restringen el uso de mayúsculas y minúsculas, pero establecen una interpretación bien definida en función de ellas. Algunas convenciones de nomenclatura especifican si se pueden utilizar caracteres alfabéticos, numéricos o alfanuméricos y, en ese caso, en qué secuencia.

Una recomendación habitual es "Utilizar identificadores significativos". Una sola palabra puede no ser tan significativa o específica como varias palabras. Por consiguiente, algunas convenciones de nomenclatura especifican reglas para el tratamiento de identificadores "compuestos" que contienen más de una palabra.

Como la mayoría de los lenguajes de programación no permiten espacios en blanco en los identificadores, se necesita un método para delimitar cada palabra (para que sea más fácil para los lectores posteriores interpretar qué caracteres pertenecen a qué palabra). Históricamente, algunos de los primeros lenguajes, en particular FORTRAN (1955) y ALGOL (1958), permitían espacios dentro de los identificadores, determinando el final de los identificadores por contexto. Esto se abandonó en lenguajes posteriores debido a la dificultad de la tokenización . Es posible escribir nombres simplemente concatenando palabras, y esto se usa a veces, como en mypackagelos nombres de paquetes de Java, ^[4] aunque la legibilidad se ve afectada para términos más largos, por lo que generalmente se usa alguna forma de separación.

Un método consiste en delimitar palabras separadas con un carácter no alfanumérico . Los dos caracteres que se utilizan habitualmente para este fin son el guión ("-") y el guión bajo ("_"); por ejemplo, el nombre de dos palabras " two words" se representaría como " two-words" o " two_words".

El guión es utilizado por casi todos los programadores que escriben COBOL (1959), Forth (1970) y Lisp (1958); también es común en Unix para comandos y paquetes, y se utiliza en CSS . ^[5] Esta convención no tiene un nombre estándar, aunque puede denominarse lisp-case o COBOL-CASE (compárese con Pascal case ), kebab-case , brochette-case u otras variantes. ^{[6] [7] [8] [9]} De estas, kebab-case , que data al menos de 2012, ^[10] ha alcanzado cierta popularidad desde entonces. ^{[11] [12]}

Por el contrario, los lenguajes de la tradición FORTRAN/ALGOL, especialmente los lenguajes de las familias C y Pascal , usaban el guión para el operador infijo de resta y no querían requerir espacios a su alrededor (como los lenguajes de forma libre ), lo que impedía su uso en identificadores.

Una alternativa es utilizar guiones bajos; esto es común en la familia C (incluido Python), con palabras en minúsculas, que se encuentran, por ejemplo, en The C Programming Language (1978), y se conoce como snake case o snail case . Los guiones bajos con mayúsculas, como en UPPER_CASE, se usan comúnmente para macros de preprocesador de C , por lo que se conocen como MACRO_CASE, y para variables de entorno en Unix, como BASH_VERSION en bash . A veces, esto se conoce humorísticamente como SCREAMING_SNAKE_CASE (alternativamente SCREAMING_SNAIL_CASE).

Otro enfoque es indicar los límites de las palabras utilizando mayúsculas intermedias, llamadas " camelloCase ", "PascalCase" y muchos otros nombres, convirtiendo así " two words" en " twoWords" o " TwoWords" respectivamente. Esta convención se utiliza comúnmente en Pascal , Java , C# y Visual Basic . El tratamiento de las siglas en los identificadores (por ejemplo, " XML " y " HTTP " en XMLHttpRequest) varía. Algunos dictan que estén en minúsculas (por ejemplo XmlHttpRequest, ) para facilitar la escritura, la legibilidad y la facilidad de segmentación , mientras que otros las dejan en mayúsculas (por ejemplo, XMLHTTPRequest) para mayor precisión.

Algunas convenciones de nomenclatura representan reglas o requisitos que van más allá de los requisitos de un proyecto o dominio de problemas específico y, en cambio, reflejan un conjunto más amplio de principios definidos por la arquitectura del software , el lenguaje de programación subyacente u otro tipo de metodología entre proyectos.

Quizás la más conocida es la notación húngara , que codifica el propósito ("Apps Hungarian") o el tipo ("Systems Hungarian") de una variable en su nombre. ^[17] Por ejemplo, el prefijo "sz" para la variable szName indica que la variable es una cadena terminada en nulo.

Un estilo utilizado para caracteres muy cortos (ocho caracteres o menos) podría ser: LCCIIL01, donde LC sería la aplicación (cartas de crédito), C para COBOL, IIL para el subconjunto del proceso particular y 01 un número de secuencia.

Este tipo de convención todavía se utiliza activamente en mainframes que dependen de JCL y también se ve en el estilo MS-DOS 8.3 (máximo de ocho caracteres con separador de punto seguido de un tipo de archivo de tres caracteres).

El "lenguaje OF" de IBM fue documentado en un manual IMS ( Sistema de gestión de información ).

Se detalla el esquema de palabras PRIME-MODIFIER-CLASS, que constaba de nombres como "CUST-ACT-NO" para indicar "número de cuenta del cliente".

Las palabras PRIME fueron pensadas para indicar las principales "entidades" de interés para un sistema.

Se utilizaron palabras MODIFICADORAS para lograr mayor refinamiento, calificación y legibilidad.

Lo ideal sería que las palabras de CLASE fueran una lista muy corta de tipos de datos relevantes para una aplicación en particular. Las palabras de CLASE comunes podrían ser: NO (número), ID (identificador), TXT (texto), AMT (cantidad), QTY (cantidad), FL (bandera), CD (código), W (trabajo), etc. En la práctica, las palabras de CLASE disponibles serían una lista de menos de dos docenas de términos.

Las palabras de CLASE, normalmente ubicadas a la derecha (sufijo), tenían una función muy similar a la de los prefijos de notación húngara .

El propósito de las palabras CLASS, además de la coherencia, era especificar al programador el tipo de datos de un campo de datos en particular. Antes de la aceptación de los campos BOOLEAN (solo dos valores), FL (flag) indicaba un campo con solo dos valores posibles.

Las convenciones de codificación y prácticas recomendadas de Adobe sugieren estándares de nombres para ActionScript que en su mayoría son consistentes con los de ECMAScript . ^{[ cita requerida ]} El estilo de los identificadores es similar al de Java .

En Ada , el único estilo recomendado de identificadores es Mixed_Case_With_Underscores. ^[18]

En los dialectos de APL , se utiliza delta (Δ) entre palabras, p. ej. PERFΔSQUARE (en las versiones anteriores de APL no existían minúsculas). Si el nombre utilizaba letras subrayadas, se utilizaba en su lugar la barra delta (⍙).

En C y C++ , las palabras clave y los identificadores de la biblioteca estándar son en su mayoría minúsculas. En la biblioteca estándar de C , los nombres abreviados son los más comunes (por ejemplo, isalnumpara una función que prueba si un carácter es alfanumérico), mientras que la biblioteca estándar de C++ a menudo usa un guión bajo como separador de palabras (por ejemplo, out_of_range). Los identificadores que representan macros se escriben, por convención, usando solo letras mayúsculas y guiones bajos (esto está relacionado con la convención en muchos lenguajes de programación de usar identificadores en mayúsculas para constantes). Los nombres que contienen doble guión bajo o que comienzan con un guión bajo y una letra mayúscula están reservados para la implementación ( compilador , biblioteca estándar ) y no deben usarse (por ejemplo, __reservedo _Reserved). ^{[19] [20]} Esto es superficialmente similar a stropping , pero la semántica difiere: los guiones bajos son parte del valor del identificador, en lugar de ser caracteres entre comillas (como es stropping): el valor de __fooes __foo(que está reservado), no foo(pero en un espacio de nombres diferente).

Las convenciones de nomenclatura de C# generalmente siguen las pautas publicadas por Microsoft para todos los lenguajes .NET ^[21] (consulte la sección .NET a continuación), pero el compilador de C# no aplica ninguna convención.

Las pautas de Microsoft recomiendan el uso exclusivo de PascalCasey camelCase, y este último se utiliza solo para nombres de parámetros de métodos y nombres de variables locales de métodos (incluidos constlos valores locales de métodos). Se hace una excepción especial a PascalCase para los acrónimos de dos letras que comienzan con un identificador; en estos casos, ambas letras se escriben con mayúscula (por ejemplo, IOStream); este no es el caso de los acrónimos más largos (por ejemplo, XmlStream). Las pautas recomiendan además que el nombre dado a an interfaceesté PascalCaseprecedido por la letra mayúscula I, como en IEnumerable.

Las pautas de Microsoft para nombrar campos son específicas para los campos static, publicy protected; los campos que no lo son staticy que tienen otros niveles de accesibilidad (como internaly private) no están cubiertos explícitamente por las pautas. ^[22] La práctica más común es usar PascalCasepara los nombres de todos los campos, excepto para aquellos que lo son private(y ni constni static), a los que se les dan nombres que usan camelCaseprecedidos por un solo guión bajo; por ejemplo, _totalCount.

Cualquier nombre de identificador puede tener como prefijo el símbolo comercial ( @), sin que se produzca ningún cambio en el significado. Es decir, tanto como factorhacen @factorreferencia al mismo objeto. Por convención, este prefijo solo se utiliza en los casos en los que el identificador sería, de otro modo, una palabra clave reservada (como fory while), que no se puede utilizar como identificador sin el prefijo, o una palabra clave contextual (como fromy where), en cuyo caso el prefijo no es estrictamente necesario (al menos no en su declaración; por ejemplo, aunque la declaración dynamic dynamic;sea válida, esto normalmente se consideraría como dynamic @dynamic;una indicación inmediata al lector de que se trata de un nombre de variable).

En el lenguaje Dart , utilizado en el SDK de Flutter , las convenciones son similares a las de Java, excepto que las constantes se escriben en lowerCamelCase. Dart impone la regla sintáctica de que los identificadores no locales que comienzan con un guión bajo ( _) se tratan como privados (ya que el lenguaje no tiene palabras clave explícitas para el acceso público o privado). Además, los nombres de los archivos fuente no siguen la regla de Java "una clase pública por archivo fuente, el nombre debe coincidir", sino que se utiliza snake_case para los nombres de archivo. ^[23]

En Go , la convención es utilizar MixedCapso mixedCapsen lugar de guiones bajos para escribir nombres de varias palabras. Al hacer referencia a estructuras o funciones, la primera letra especifica la visibilidad para paquetes externos. Al poner la primera letra en mayúscula se exporta ese fragmento de código, mientras que en minúscula solo se puede utilizar dentro del ámbito actual. ^[24]

En Java , las convenciones de nombres para identificadores han sido establecidas y sugeridas por varias comunidades Java como Sun Microsystems, ^[25] Netscape, ^[26] AmbySoft, ^[27] etc. A continuación se muestra una muestra de las convenciones de nombres establecidas por Sun Microsystems, donde un nombre en " CamelCase " es uno compuesto por una serie de palabras unidas sin espacios, con la letra inicial de cada palabra (excluyendo la primera) en mayúsculas, por ejemplo "camelCase".

Los compiladores de Java no hacen cumplir estas reglas, pero no seguirlas puede generar confusión y código erróneo. Por ejemplo, widget.expand()y Widget.expand()implican comportamientos significativamente diferentes: widget.expand()implica una invocación a un método expand()en una instancia denominada widget, mientras que Widget.expand()implica una invocación a un método estático expand()en la clase Widget.

Un estilo de codificación Java ampliamente utilizado dicta que UpperCamelCasese use para clases y lowerCamelCasese use para instancias y métodos . ^[25] Reconociendo este uso, algunos IDE , como Eclipse , implementan atajos basados ​​en CamelCase. Por ejemplo, en la función de asistencia de contenido de Eclipse , escribir solo las letras mayúsculas de una palabra CamelCase sugerirá cualquier nombre de clase o método coincidente (por ejemplo, escribir "NPE" y activar la asistencia de contenido podría sugerir NullPointerException).

Las iniciales de tres o más letras se escriben en CamelCase en lugar de mayúsculas (por ejemplo, parseDbmXmlFromIPAddressen lugar de parseDBMXMLFromIPAddress). También se puede establecer el límite en dos o más letras (por ejemplo, parseDbmXmlFromIpAddress).

Las bibliotecas integradas de JavaScript utilizan las mismas convenciones de nombres que Java. Los tipos de datos y las funciones constructoras utilizan mayúsculas ( RegExp, TypeError, XMLHttpRequest, DOMObject) y los métodos utilizan minúsculas ( getElementById, getElementsByTagNameNS, createCDATASection). Para mantener la coherencia, la mayoría de los desarrolladores de JavaScript siguen estas convenciones. ^[28] Véase también: Convenciones de Douglas Crockford

Una práctica común en la mayoría de los dialectos de Lisp es usar guiones para separar palabras en identificadores, como en with-open-filey make-hash-table. Los nombres de variables dinámicas comienzan y terminan convencionalmente con asteriscos: *map-walls*. Los nombres de constantes se marcan con signos más: +map-size+. ^{[29] [30]}

Microsoft .NET recomienda UpperCamelCase, también conocido como PascalCase , para la mayoría de los identificadores. ( lowerCamelCasese recomienda para parámetros y variables ) y es una convención compartida para los lenguajes .NET. ^[31] Microsoft recomienda además que no se utilicen sugerencias de prefijo de tipo (también conocidas como notación húngara ). ^[32] En lugar de utilizar la notación húngara, se recomienda finalizar el nombre con el nombre de la clase base; LoginButtonen lugar de BtnLogin. ^[33]

Objective-C tiene un estilo de codificación común que tiene sus raíces en Smalltalk .

Las entidades de nivel superior, incluidas las clases, los protocolos, las categorías y las construcciones de C que se utilizan en programas Objective-C, como las variables y funciones globales, se escriben en UpperCamelCase con un prefijo corto en mayúsculas que denota un espacio de nombres, como , NSStringo . Las constantes pueden tener como prefijo opcional una letra "k" minúscula, como .UIAppDelegateNSAppCGRectMakekCFBooleanTrue

Las variables de instancia de un objeto usan lowerCamelCase con el prefijo de un guión bajo, como _delegatey _tableView.

Los nombres de métodos utilizan varias partes lowerCamelCase separadas por dos puntos que delimitan los argumentos, como: application:didFinishLaunchingWithOptions:, stringWithFormat:y isRunning.

Los lenguajes wirthianos Pascal, Modula-2 y Oberon generalmente utilizan identificadores Capitalizedo UpperCamelCasepara programas, módulos, constantes, tipos y procedimientos, y lowercaseo lowerCamelCaseidentificadores para constantes matemáticas, variables, parámetros formales y funciones. ^[34] Si bien algunos dialectos admiten el uso de guiones bajos y signos de dólar en los identificadores, es más probable que el uso de mayúsculas y minúsculas y mayúsculas y minúsculas se limite al uso dentro de interfaces API externas. ^[35]

Perl toma algunas señales de su herencia de C para las convenciones. Las variables de ámbito local y los nombres de subrutinas se escriben en minúsculas con guiones bajos infijos. Las subrutinas y variables que se deben tratar como privadas se anteponen con un guión bajo. Las variables de paquete se escriben en mayúsculas y minúsculas. Las constantes declaradas se escriben en mayúsculas y minúsculas. Los nombres de paquete se escriben en mayúsculas y minúsculas, excepto los pragmas (por ejemplo, stricty mro), que se escriben en minúsculas. ^{[36] [37]}

Las recomendaciones de PHP están contenidas en PSR-1 ( Recomendación estándar PHP 1) y PSR-12. ^[38] Según PSR-1, los nombres de clase deben estar en PascalCase, las constantes de clase deben estar en MACRO_CASE y los nombres de funciones y métodos deben estar en camelCase. ^[39]

Tanto Python como RubyUpperCamelCase lo recomiendan para nombres de clases, CAPITALIZED_WITH_UNDERSCORESconstantes y snake_caseotros nombres.

En Python, si se pretende que un nombre sea " privado ", se le anteponen uno o dos guiones bajos. Las variables privadas se aplican en Python solo por convención. Los nombres también pueden anteponerse con un guión bajo para evitar conflictos con las palabras clave de Python. El anteponer guiones bajos dobles cambia el comportamiento de las clases en lo que respecta a la alteración de nombres . El anteponer y sufijar con guiones bajos dobles (los métodos denominados "dunder" ("double under") en Python) se reserva para los "nombres mágicos" que cumplen un comportamiento especial en los objetos de Python. ^[40]

Si bien no existe una guía de estilo oficial para R , la guía de estilo tidyverse del gurú de R Hadley Wickham establece el estándar para la mayoría de los usuarios. ^[41] Esta guía recomienda evitar caracteres especiales en los nombres de archivos y usar solo números, letras y guiones bajos para los nombres de variables y funciones, por ejemplo, fit_models.R.

Raku sigue más o menos las mismas convenciones que Perl, excepto que permite un guión infijo -o un apóstrofo '(o comilla simple) dentro de un identificador (pero no dos seguidos), siempre que esté seguido de un carácter alfabético. Por ello, los programadores de Raku suelen utilizar la combinación de mayúsculas y minúsculas en sus identificadores; por ejemplo, fish-foody don't-do-thatson identificadores válidos. ^[42]

Rust recomienda UpperCamelCasepara alias de tipo y nombres de estructuras, rasgos, enumeraciones y variantes de enumeraciones, SCREAMING_SNAKE_CASEpara constantes o estáticas y snake_casepara nombres de variables, funciones y miembros de estructuras. ^[43]

Swift ha cambiado sus convenciones de nomenclatura con cada versión individual. Sin embargo, una actualización importante con Swift 3.0 estabilizó las convenciones de nomenclatura para lowerCamelCaselas declaraciones de variables y funciones. Las constantes suelen definirse mediante tipos de enumeración o parámetros constantes que también se escriben de esta manera. Las declaraciones de clases y otros tipos de objetos son UpperCamelCase.

A partir de Swift 3.0, se han establecido pautas de nomenclatura claras para el lenguaje en un esfuerzo por estandarizar las convenciones de nomenclatura y declaración de API en todas las API de terceros. ^[44]

• Categoría:Convenciones de nombres
• Estilo de cuadros
• Convenciones de codificación
• Lista de herramientas para el análisis de código estático
• Espacio de nombres
• Convención de nombres
• Sigilo (programación informática)
• Sintaxis (lenguajes de programación)

• coding-guidelines.com tiene un PDF que utiliza la lingüística y la psicología para intentar un análisis de costo/beneficio de los problemas de denominación de identificadores.