En programación , una convención de nomenclatura es un conjunto de reglas para nombrar identificadores que representan variables , tipos , funciones y otras cosas en el código fuente y la documentación .
Las convenciones, en lugar de usar nombres arbitrarios, se pueden usar para realizar las siguientes tareas:
La elección de las convenciones de nomenclatura puede ser un tema extremadamente polémico, ya que los defensores de cada una ven sus convenciones como las mejores y otras como las peores. En el lenguaje común, tales discusiones se llaman "holivars" (del inglés guerra santa - guerra santa ) [2] . Muchas empresas establecen sus propios acuerdos [3] [4] [5] [6] [7] [8] .
Algunos de los beneficios potenciales que se pueden obtener al adoptar una convención de nomenclatura son:
La elección de las convenciones de nombres (y la medida en que se aplican) es a menudo un tema polémico, ya que los defensores se aferran a su punto de vista como el mejor y otros como el peor. Además, incluso si existen convenciones de nomenclatura conocidas y bien definidas, es posible que algunas organizaciones no se adhieran a ellas de manera consistente, lo que genera incoherencias y confusión. Estos problemas pueden exacerbarse si las reglas de la convención de nomenclatura son internamente inconsistentes, arbitrarias, difíciles de recordar o se perciben como más onerosas que útiles.
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 aplicarlo a las nuevas necesidades.
Por ejemplo, aunque
a = b * c;sintácticamente correcto, su propósito no es obvio. Compara esto con:
pago_semanal = horas_trabajadas * tarifa_pago_por_hora;lo que implica entender el código fuente, al menos para aquellos familiarizados con el contexto de la afirmación.
Las reglas exactas para las convenciones de nomenclatura dependen del contexto en el que se utilizan. Sin embargo, hay algunos elementos comunes que influyen en la mayoría, si no en todas, las convenciones de nomenclatura de uso común en la actualidad.
Los elementos fundamentales de todas las convenciones de nomenclatura son reglas relacionadas con la longitud de un identificador (es decir, el número finito de caracteres distintos permitidos en un identificador). Algunas reglas prescriben un límite numérico fijo, mientras que otras especifican valores o recomendaciones menos precisos.
Las reglas de longitud del identificador son comúnmente cuestionadas en la práctica y son objeto de mucho debate académico.
Algunas consideraciones:
Es una pregunta abierta de investigación si algunos programadores prefieren identificadores más cortos porque son más fáciles de escribir o crear que identificadores más largos, o porque en muchas situaciones un identificador más largo simplemente abarrota el código visible y no proporciona ningún beneficio adicional visible.
La brevedad en la programación se explica en parte por:
Algunas convenciones de nomenclatura restringen la visualización de letras en mayúsculas o minúsculas. Otras convenciones no restringen las mayúsculas y minúsculas, pero agregan una interpretación bien definida basada en mayúsculas y minúsculas. Algunas convenciones de nomenclatura especifican si se pueden usar caracteres alfabéticos, numéricos o alfanuméricos y, de ser así, en qué orden.
La recomendación general es "Usar identificadores significativos". Una palabra puede no ser tan significativa o específica como varias palabras. Por lo tanto, algunas convenciones de nombres especifican reglas para manejar identificadores "compuestos" que contienen más de una palabra.
Dado que la mayoría de los lenguajes de programación no permiten espacios en los identificadores, se necesita un método para separar cada palabra (para que sea más fácil para los lectores posteriores interpretar qué caracteres pertenecen a qué palabra). Históricamente, algunos lenguajes antiguos, en particular FORTRAN (1955) y ALGOL (1958), permitían espacios en los identificadores determinando el final de los identificadores por contexto. Esto ha sido abandonado 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 [9] , aunque la legibilidad se ve afectada con términos más largos, por lo que generalmente se usa alguna forma de separación.
Palabras separadas por delimitadoresUn enfoque consiste en separar palabras individuales con caracteres no alfanuméricos. Normalmente se utilizan dos caracteres para este propósito: un guión ("-") y un guión bajo ("_"); por ejemplo, un nombre de dos palabras «two words»se representaría como «two-words»o «two_words». Casi todos los programadores de COBOL (1959), Forth (1970) y Lisp (1958) utilizan el guión; también es común en Unix para comandos y paquetes, y se usa en CSS [10] . Esta convención no tiene un nombre estándar, aunque puede llamarse lisp-case o COBOL-CASE (compárese con Pascal case ), kebab-case , brochette-case u otras variaciones [11] [12] [13] [14] . De estos , el caso kebab , que data de al menos 2012 [15] , desde entonces se ha hecho popular [16] [17] .
Por el contrario, los lenguajes en la tradición FORTRAN/ALGOL, especialmente los de las familias C y Pascal , usaban el guión para el operador de resta infijo , y no querían requerir espacios a su alrededor (como los lenguajes de forma libre), impidiendo su uso en identificadores. Una alternativa es usar un guión bajo; esto es común en la familia C (incluido Python), donde aparecen palabras en minúsculas, como en el lenguaje de programación C (1978) y se conoció como caso serpiente . Los guiones bajos en 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 de Unix como BASH_VERSION en bash . Esto a veces se denomina con humor como SCREAMING_SNAKE_CASE.
Palabras separadas por letrasOtro enfoque es indicar los límites de las palabras usando mayúsculas intermedias llamadas " camelCase ", "Pascal case" y muchos otros nombres, mostrando así «two words»como «twoWords»o respectivamente «TwoWords». Esta convención se usa comúnmente en Pascal , Java , C# y Visual Basic . El manejo de iniciales en identificadores (como " XML " y " HTTP " en XMLHttpRequest) varía. Algunos creen que deberían estar en minúsculas (p. ej XmlHttpRequest.) para facilitar la escritura y la legibilidad, mientras que otros los dejan en mayúsculas (p. ej XMLHTTPRequest.) para mayor precisión.
Ejemplos de formatos de identificadores detallados| Formato | Nombre |
|---|---|
| twowords | caja plana [18] [19] |
| TWOWORDS | caja superior plana [18] |
| twoWords | (inferior) CamelCase , dromedaryCase |
| TwoWords | (superior) CamelCase , PascalCase, StudlyCase [20] |
| two_words | caso de serpiente , bache_caso |
| TWO_WORDS | CASO DE SERPIENTE GRITANDO , MACRO_CASO, CONSTANTE_CASO |
| Two_Words | Camel_Snake_Case [21] |
| two-words | caja de kebab , caja de guión , caja de ceceo |
| TWO-WORDS | TRAIN-CASE, COBOL-CASE, SCREAMING-KEBAB-CASE |
| Two-Words | Caso de tren, [18] Caso de encabezado HTTP [21] |
Algunas convenciones de nomenclatura son reglas o requisitos que van más allá de los requisitos de un proyecto o dominio en particular y, en cambio, reflejan un conjunto más amplio de principios definidos por una arquitectura de software , un lenguaje de programación subyacente u otra metodología entre proyectos.
Quizás la más conocida es la notación húngara , que codifica el propósito ("Aplicaciones húngaras") o el tipo ("Sistemas húngaros") de una variable en su nombre [22] . Por ejemplo, el prefijo "sz" para la variable szName indica que la variable es una cadena terminada en nulo.
El estilo utilizado para muy breve (ocho caracteres o menos) podría ser: LCCIIL01, donde LC es adjunto (cartas de crédito), C para COBOL, IIL para un subconjunto específico de procesos y 01 es un número de secuencia.
Esta convención todavía está en uso activo en mainframes que dependen del JCL y también se encuentra en el estilo MS-DOS 8.3 (máximo de ocho caracteres con un punto de separación seguido de un tipo de archivo de tres caracteres).
El "Lenguaje OF" de IBM se documentó en el manual IMS ( Sistema de gestión de la información ).
Detalla el esquema de palabras PRIME-MODIFIER-CLASS, que consta de nombres como "CUST-ACT-NO" para "número de cuenta del cliente".
Las palabras PRIME estaban destinadas a denotar las principales "entidades" de interés para el sistema.
Las palabras MODIFICADOR se han utilizado para mayor aclaración, refinamiento y legibilidad.
Idealmente, las palabras CLASS serían una lista muy corta de tipos de datos específicos de la aplicación. Las palabras comunes de CLASE pueden 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án una lista de menos de dos docenas de términos.
Las palabras CLASS, que generalmente se colocan a la derecha (sufijo), tienen casi el mismo propósito que los prefijos de designación húngaros .
El propósito de las palabras CLASS, además de la coherencia, era indicar al programador el tipo de datos de un campo de datos en particular. Antes de aceptar campos BOOLEAN (solo dos valores), FL (bandera) apuntará a un campo con solo dos valores posibles.
Adobe Coding Conventions and Best Practices proporciona estándares de nomenclatura para ActionScript que en su mayoría siguen los estándares ECMAScript . El estilo de los identificadores es similar al de Java .
En Ada , el único estilo recomendado para los identificadores es Mixed_Case_With_Underscores[23] .
Los dialectos de APL usan un delta (Δ) entre palabras, como PERFΔSQUARE (tradicionalmente no había letras minúsculas en versiones anteriores de APL). Si se usan letras subrayadas en el nombre, en su lugar se usará un guión delta subrayado (⍙).
En C y C++ , las palabras clave y los identificadores de la biblioteca estándar se escriben principalmente en minúsculas. En la biblioteca estándar de C, las abreviaturas son las más comunes (por ejemplo, isalnumpara una función que verifica si un carácter es alfanumérico), mientras que la biblioteca estándar de C++ suele usar guiones bajos como separadores 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 se debe a la convención en muchos lenguajes de programación de usar solo identificadores en mayúsculas para las constantes). Los nombres que contienen guiones bajos dobles 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) [24] [25] . Esto es superficialmente similar a slinging, pero la semántica es diferente: los guiones bajos son parte del valor del identificador, en lugar de entrecomillar caracteres (como slinging): el valor __fooes __foo(que está reservado) no foo(pero en un espacio de nombres diferente).
Las convenciones de nomenclatura de C# generalmente siguen las recomendaciones publicadas por Microsoft para todos los lenguajes NET [26] (consulte NET a continuación), pero el compilador de C# no aplica ninguna convención.
El manual de Microsoft recomienda el uso exclusivo de solo PascalCase y CamelCase , este último se usa solo para nombres de parámetros y nombres de variables de métodos de constvalores locales (incluido el método local). Se hace una excepción especial para PascalCase para los acrónimos de dos letras que comienzan con un identificador; en estos casos, ambas letras son IOStreamletras (por ejemplo, IOStream); esto no se aplica a los acrónimos más largos (p. ej XmlStream., ). El manual también recomienda que el nombre dado interfacesea PascalCase precedido por una I mayúscula , como en IEnumerable.
Las pautas de nomenclatura de campos de Microsoft se aplican a los campos y static; los campos que no lo son y tienen otros niveles de accesibilidad (por ejemplo, y ) claramente no están sujetos a las pautas [27] . La práctica más común es usar PascalCase para todos los nombres de campo, excepto para aquellos que son (y no son ni , ni ), que reciben nombres que usan camelCase precedidos por un solo guión bajo; por ejemplo, . publicprotectedstaticinternalprivateprivateconststatic_totalCount
Cualquier nombre de identificador puede comenzar con un carácter de comillas ( @ ) sin cambiar el significado. Es decir, y factor, y @factorse refieren al mismo objeto. Por convención, este prefijo se usa solo cuando el identificador sería una palabra clave reservada (por ejemplo, fory while) que no se puede usar como un identificador sin prefijo, o una palabra clave contextual (por ejemplo, fromy where), en cuyo caso el El prefijo no es estrictamente necesario (al menos no cuando se declara; por ejemplo, aunque la declaración dynamic dynamic;es válida, se suele ver como dynamic @dynamic;para indicar inmediatamente al lector que este último es un nombre de variable).
En Go , se acostumbra usar MixedCapso mixedCapsen lugar de subrayar para escribir nombres detallados. Cuando se hace referencia a clases o funciones, la primera letra indica visibilidad a paquetes externos. Si convierte la primera letra en mayúscula, este fragmento de código se exportará, mientras que las minúsculas solo se utilizarán en el ámbito actual [28] .
En Java , varias comunidades de Java, como Sun Microsystems [29] , Netscape [30] , AmbySoft [31] , etc., han desarrollado y propuesto convenciones de nomenclatura para identificadores . A continuación se enumeran ejemplos de convenciones de nomenclatura establecidas por Sun Microsystems, donde nombre en " CamelCase " consta de varias palabras concatenadas sin espacios, con la letra mayúscula inicial de cada palabra, como "CamelCase".
| Tipo de identificador | Reglas de nomenclatura | Ejemplos |
|---|---|---|
| Clases | Los nombres de las clases deben ser sustantivos en , la primera letra de cada palabra debe estar en mayúscula. Use palabras completas: evite los acrónimos y las abreviaturas (a menos que la abreviatura se use mucho más ampliamente que la forma larga, como URL o HTML). Upper CamelCase |
|
| Métodos | Los métodos deben ser verbos en mayúsculas y minúsculas o nombres de varias palabras que comiencen con un verbo en minúsculas; es decir, la primera letra en minúsculas y las primeras letras de las palabras posteriores en mayúsculas. lower CamelCaselower CamelCase |
|
| Variables | Las variables locales, las variables de instancia y las variables de clase también se escriben en . Los nombres de variables no deben comenzar con un guión bajo ( ) o un signo de dólar ( ), incluso si ambos están permitidos. Esto contrasta con otras convenciones de codificación, que establecen que todas las variables de instancia deben tener un prefijo de guiones bajos.
lower CamelCase_$ Los nombres de las variables deben ser breves pero significativos. La elección del nombre de la variable debe ser mnemotécnica, es decir, con la intención de indicar al observador casual el propósito de su uso. Deben evitarse los nombres de variables de un solo carácter, con la excepción de las variables temporales "únicas". Nombres de variables temporales comunes: i, j, k, myn para números enteros; c, d y e para los caracteres. |
|
| constantes | Las constantes deben escribirse en mayúsculas separadas por guiones bajos. Los nombres constantes también pueden contener números si es necesario, pero no como el primer carácter. |
|
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()e Widget.expand()implica un comportamiento significativamente diferente: widget.expand()implica una llamada a un método en una expand()instancia denominada widget, mientras que Widget.expand()implica una llamada a un método estático. en expand()claseWidget
Un estilo de codificación de Java ampliamente utilizado requiere que UpperCamelCase se use para clases y lowerCamelCase para instancias y métodos [29] . Reconociendo este uso, algunos IDE como Eclipse implementan accesos directos basados en CamelCase. Por ejemplo, en la función de asistencia de contenido de Eclipse, escribir en mayúsculas la palabra CamelCase sugerirá cualquier clase o nombre de método adecuado (por ejemplo, escribir "NPE" y activar el asistente de contenido puede sugerir NullPointerException).
Siglas de tres o más letras - CamelCase en lugar de mayúsculas (por ejemplo, parseDbmXmlFromIPAddressen lugar de parseDBMXMLFromIPAddress). También puede establecer un borde de dos o más letras (por ejemplo, parseDbmXmlFromIpAddress).
Las bibliotecas de JavaScript integradas utilizan las mismas convenciones de nomenclatura que Java. Los tipos de datos y las funciones del constructor usan mayúsculas ( RegExp , TypeError , XMLHttpRequest , DOMObject ) y los métodos usan minúsculas ( getElementById , getElementsByTagNameNS , createCDATASection ). Para ser coherente, la mayoría de los desarrolladores de JavaScript siguen estas convenciones [32] [33] .
La práctica común en la mayoría de los dialectos Lisp es usar guiones para separar palabras en identificadores, como en with-open-filey make-hash-table. Los nombres de las variables dinámicas suelen empezar y terminar con asteriscos: *map-walls*. Los nombres constantes están marcados con un signo más: +map-size+[34] [35] .
Microsoft .NET recomienda UpperCamelCase , también conocido como PascalCase , para la mayoría de los identificadores. Para parámetros y variables , se recomienda usar lowerCamelCase ), que es una convención general para lenguajes .NET [36] . Microsoft también recomienda no usar sugerencias de prefijo de tipo (también conocidas como notación húngara [37] . En lugar de usar la notación húngara, se recomienda que termine el nombre con el nombre de la clase base: LoginButtonen lugar BtnLoginde [38] .
Objective-C tiene un estilo de programación general arraigado en Smalltalk .
Las entidades de nivel superior, incluidas las clases, los protocolos, las categorías y las construcciones de C que se usan en los programas de Objective-C, como las variables y funciones globales, están en UpperCamelCase con un prefijo corto en mayúsculas que indica el espacio de nombres, por ejemplo , NSString , UIAppDelegate . NSApp o CGRectMake . Las constantes se pueden prefijar opcionalmente con una "k" minúscula, como kCFBooleanTrue .
Las variables de objeto usan lowerCamelCase con el prefijo de un guión bajo, como _delegate y _tableView .
Los nombres de los métodos usan varias partes lowerCamelCase separadas por dos puntos que separan los argumentos, por ejemplo: application: didFinishLaunchingWithOptions: , stringWithFormat: and isRunning .
Los lenguajes Pascal, Modula-2 y Oberon suelen utilizar identificadores Capitalizedo UpperCamelCasepara programas, módulos, constantes, tipos y procedimientos, e lowerCamelCaseidentificadores lowercaseo lowerCamelCasepara constantes matemáticas, variables, parámetros formales y funciones [39] . Si bien algunos dialectos admiten guiones bajos y signos de dólar en los identificadores, es probable que el uso de mayúsculas y minúsculas y macros se limite al uso en API externas [40] .
Perl toma algunas reglas de su herencia C. Los nombres de subprogramas variables y de ámbito local se escriben en letras minúsculas con guiones bajos infijos. Las subrutinas y variables que deben tratarse como privadas tienen un prefijo de subrayado. Las variables del paquete se incluyen en un encabezado. Todas las constantes declaradas se escriben con mayúscula. Los nombres de los paquetes se escriben en mayúsculas, excepto pragmas como stricty mro, que se mroescriben en minúsculas [41] [42] .
Las recomendaciones PHP están contenidas en PSR-1 (recomendación estándar PHP 1) y PSR-12 [43] . De acuerdo con PSR-1, los nombres de las clases deben estar en PascalCase, las constantes de clase deben estar en MACRO_CASE y los nombres de los métodos deben estar en camelCase [44] .
Se recomiendan Python y RubyUpperCamelCase para nombres de clases, CAPITALIZED_WITH_UNDERSCORESconstantes y lowercase_separated_by_underscoresotros nombres.
En Python, si un nombre va a ser " privado " dentro de un módulo, se recomienda que comience con un solo guión bajo. Los nombres también pueden terminar con un solo guión bajo para evitar conflictos con las palabras clave de Python. El prefijo de doble guión bajo, por otro lado, distorsiona la representación externa de los nombres de los miembros de la clase: por ejemplo, en una clase, FooBarun método __boofuera de la clase será visible como _FooBar__boo. Los nombres que comienzan y terminan con un doble guión bajo están reservados para "nombres mágicos" que desempeñan un papel especial en Python (p. ej., __init__, __import__, __file__) [45] .
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 [46] . Esta guía recomienda evitar los caracteres especiales en los nombres de archivo y usar solo números, letras y guiones bajos para los nombres de variables y funciones, como fit_models. r
Raku sigue más o menos las mismas reglas que Perl, excepto que Raku permite guiones internos y apóstrofes (comillas simples) siempre que vayan seguidos de letras. Por lo tanto, kebab -case se puede usar en Raku : por ejemplo, fish-foody don't-do-thatson identificadores válidos [47] .
Rust recomienda UpperCamelCasestruct, trait, enum y enum para alias de tipos y nombres de variantes, SCREAMING_SNAKE_CASEpara constantes o variables estáticas, y snake_casepara nombres de variables, funciones y estructuras [48] .
Swift cambia sus convenciones de nombres con cada lanzamiento. Sin embargo, la actualización principal de Swift 3.0 estabilizó las convenciones de nomenclatura para lowerCamelCasevariables y declaraciones de funciones. Las constantes generalmente se definen mediante tipos enumerados o parámetros constantes, que también se escriben de la misma manera. Las declaraciones de clases y otros tipos de objetos son UpperCamelCase.
Desde Swift 3.0, se han formulado pautas de nomenclatura claras para el lenguaje con el objetivo de estandarizar las convenciones de nomenclatura y las declaraciones de API para todas las API de terceros [49] .