En programación de computadoras , 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 nomenclatura (en lugar de permitir a los programadores elegir cualquier secuencia de caracteres) incluyen las siguientes:
La elección de las convenciones de nomenclatura puede ser un tema controvertido, ya que los partidarios de cada uno consideran que la suya es la mejor y que los demás son inferiores. Coloquialmente 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 los siguientes:
La elección de las convenciones de nomenclatura (y el grado en que se aplican) es a menudo un tema polémico, ya que los partidarios sostienen que su punto de vista es el mejor y otros inferiores. Además, incluso con convenciones de nomenclatura conocidas y bien definidas, es posible que algunas organizaciones no las cumplan de manera consistente, lo que genera inconsistencia y confusión. Estos desafíos pueden verse exacerbados si las reglas de la convención de nomenclatura son internamente inconsistentes, arbitrarias, difíciles de recordar o se perciben de alguna otra manera 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. Contraste esto con:
pago_semanal = horas_trabajadas * tasa_de_pago_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]
Las reglas exactas de una convención de nomenclatura dependen del contexto en el que se emplean. Sin embargo, hay varios 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 las reglas relacionadas con la longitud del identificador (es decir, el número finito 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 se cuestionan habitualmente en la práctica y están sujetas a mucho debate académico.
Algunas consideraciones:
Es un tema de investigación abierto si algunos programadores prefieren identificadores más cortos porque son más fáciles de escribir o pensar que los 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:
Algunas convenciones de nomenclatura limitan si las letras pueden aparecer en mayúsculas o minúsculas. Otras convenciones no restringen las mayúsculas y minúsculas, pero adjuntan una interpretación bien definida basada en mayúsculas y minúsculas. Algunas convenciones de nomenclatura especifican si se pueden utilizar caracteres alfabéticos, numéricos o alfanuméricos y, de ser así, en qué secuencia.
Una recomendación común es "Utilizar identificadores significativos". Una sola palabra puede no ser tan significativa o específica como varias palabras. En consecuencia, 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 lenguajes antiguos, 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 idiomas posteriores debido a la dificultad de la tokenización . Es posible escribir nombres simplemente concatenando palabras, y esto a veces se usa, como para 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 comúnmente utilizados para este propósito 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".
Casi todos los programadores que escriben 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 . [5] Esta convención no tiene un nombre estándar, aunque puede denominarse lisp-case o COBOL-CASE (compárese con Pascal ), kebab-case , brochette-case u otras variantes. [6] [7] [8] [9] De estos, kebab-case , que data al menos de 2012, [10] ha logrado cierta vigencia desde entonces. [11] [12]
Por el contrario, los lenguajes de la tradición FORTRAN/ALGOL, en particular los lenguajes de las familias C y Pascal , usaban el guión para el operador infijo de resta y no deseaban requerir espacios a su alrededor (como lenguajes de forma libre ), impidiendo su uso en identificadores.
Una alternativa es utilizar guiones bajos; esto es común en la familia C (incluido Python), con palabras en minúscula, que se encuentran por ejemplo en The C Programming Language (1978), y ha llegado a ser conocido como caso de serpiente o caso de caracol . 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 denomina con humor SCREAMING_SNAKE_CASE (alternativamente SCREAMING_SNAIL_CASE).
Otro enfoque es indicar los límites de las palabras usando mayúsculas medias, llamadas " camelCase ", "PascalCase" y muchos otros nombres, representando así respectivamente " two words" como " twoWords" o " TwoWords". Esta convención se usa comúnmente en Pascal , Java , C# y Visual Basic . El tratamiento de las iniciales en los identificadores (por ejemplo, " XML " y " HTTP " en XMLHttpRequest) varía. Algunos dictan que estén en minúsculas (p. ej. XmlHttpRequest) para facilitar la escritura, la legibilidad y la segmentación , mientras que otros los dejan en mayúsculas (p. ej. 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 problema 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 sea 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. [17] Por ejemplo, el prefijo "sz" para la variable szName indica que la variable es una cadena terminada en nulo.
Un estilo usado para caracteres muy cortos (ocho caracteres y menos) podría ser: LCCIIL01, donde LC sería la aplicación (Cartas de crédito), C para COBOL, IIL para el subconjunto de proceso particular y el 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 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 ).
Detallaba el esquema de palabras PRIME-MODIFIER-CLASS, que consistía en nombres como "CUST-ACT-NO" para indicar "número de cuenta del cliente".
Las palabras PRIME estaban destinadas a indicar "entidades" importantes de interés para un sistema.
Se utilizaron palabras MODIFICADORES para mayor refinamiento, calificación y legibilidad.
Idealmente, las palabras CLASS serían una lista muy corta de tipos de datos relevantes para una aplicación particular. Las palabras comunes de CLASS 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 CLASS disponibles serían una lista de menos de dos docenas de términos.
Las palabras CLASS, normalmente colocadas a la derecha (sufijo), tenían el mismo propósito que 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 campos BOOLEANOS (solo dos valores), FL (bandera) indicaría un campo con solo dos valores posibles.
Las convenciones de codificación y mejores prácticas de Adobe sugieren estándares de nombres para ActionScript que sean en su mayoría consistentes con los de ECMAScript . [ cita necesaria ] 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 APL , el delta (Δ) se usa entre palabras, por ejemplo, PERFΔSQUARE (tradicionalmente no existían minúsculas en las versiones anteriores de APL). Si el nombre usa letras subrayadas, entonces se usará la barra inferior delta (⍙).
En C y C++ , las palabras clave y los identificadores de biblioteca estándar están en su mayoría en 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++ suele utilizar un guión bajo como separador de palabras (por ejemplo, out_of_range). Los identificadores que representan macros , por convención, se escriben utilizando únicamente letras mayúsculas y guiones bajos (esto está relacionado con la convención en muchos lenguajes de programación de utilizar identificadores exclusivamente en mayúsculas para las 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 comillas (como lo es el 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 only PascalCasey camelCase, y este último se usa solo para nombres de parámetros de métodos y nombres de variables locales de método (incluidos constvalores locales de método). Se hace una excepción especial a PascalCase para las siglas de dos letras que comienzan con un identificador; en estos casos, ambas letras están en mayúscula (por ejemplo, IOStream); este no es el caso de acrónimos más largos (por ejemplo, XmlStream). Las directrices recomiendan además que el nombre dado a un interfaceesté PascalCaseprecedido por la letra mayúscula I, como en IEnumerable.
Las pautas de Microsoft para nombrar campos son específicas para static, publicy protectedcampos; 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 aquellos que lo son private(y ni constni static), a los que se les da 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 ningún cambio en su significado. Es decir, ambos factory @factorse refieren al mismo objeto. Por convención, este prefijo sólo se utiliza en casos en los que el identificador sería, de otro modo, una palabra clave reservada (como fory while), que no puede utilizarse como identificador sin el prefijo, o una palabra clave contextual (como fromy where), en la que En algunos casos, el prefijo no es estrictamente necesario (al menos no en su declaración; por ejemplo, aunque la declaración dynamic dynamic;es válida, normalmente se consideraría que esto dynamic @dynamic;indica al lector inmediatamente que este último es un nombre de variable).
En el lenguaje Dart , utilizado en Flutter SDK , las convenciones son similares a las de Java, excepto que las constantes están escritas 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 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 utilizan Snake_case para los nombres de archivos. [23]
En Go , la convención es utilizar MixedCapso mixedCapsen lugar de guiones bajos para escribir nombres de varias palabras. Cuando se hace referencia a estructuras o funciones, la primera letra especifica la visibilidad de paquetes externos. Al poner la primera letra en mayúscula se exporta ese fragmento de código, mientras que en minúsculas solo se puede utilizar dentro del alcance actual. [24]
En Java , varias comunidades de Java, como Sun Microsystems, [25] Netscape, [26] AmbySoft, [27], etc. , han establecido y sugerido convenciones de nomenclatura para identificadores . A continuación se enumera una muestra de convenciones de nomenclatura establecidas por Sun Microsystems, donde un nombre en " CamelCase " es aquel compuesto por un número de palabras unidas sin espacios, con la letra inicial de cada palabra (excluyendo la primera palabra) en mayúsculas (por ejemplo, "camelCase").
Los compiladores de Java no imponen estas reglas, pero no seguirlas puede generar confusión y código erróneo. Por ejemplo, widget.expand()e Widget.expand()implica 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 una clase Widget.
Un estilo de codificación Java ampliamente utilizado dicta que UpperCamelCasese use para clases y lowerCamelCasepara instancias y métodos . [25]
Al reconocer 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).
Los inicialismos de tres o más letras son 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 de JavaScript integradas utilizan las mismas convenciones de nomenclatura que Java. Los tipos de datos y las funciones constructoras usan mayúsculas camel ( RegExp,,, ) y los métodos usan minúsculas camel ( ,, ). Para ser coherentes, la mayoría de los desarrolladores de JavaScript siguen estas convenciones. [28]
Ver también: Convenciones de Douglas CrockfordTypeErrorXMLHttpRequestDOMObjectgetElementByIdgetElementsByTagNameNScreateCDATASection
La práctica común en la mayoría de los dialectos Lisp es utilizar guiones para separar palabras en identificadores, como en with-open-filey make-hash-table. Los nombres de variables dinámicas convencionalmente comienzan y terminan con asteriscos: *map-walls*. Los nombres de las constantes están marcados 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 terminar 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 clases, protocolos, categorías y construcciones C que se utilizan en programas Objective-C como variables y funciones globales, están en UpperCamelCase con un prefijo corto en mayúsculas que denota espacio de nombres, como NSString, o . Opcionalmente, las constantes pueden tener el prefijo "k" minúscula, como .UIAppDelegateNSAppCGRectMakekCFBooleanTrue
Las variables de instancia de un objeto utilizan lowerCamelCase con el prefijo de guión bajo, como _delegatey _tableView.
Los nombres de los 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 usan Capitalizedidentificadores UpperCamelCasepara programas, módulos, constantes, tipos y procedimientos, y lowercaseidentificadores lowerCamelCasepara constantes matemáticas, variables, parámetros formales y funciones. [34] Si bien algunos dialectos admiten guiones bajos y signos de dólar en los identificadores, es más probable que el caso de serpiente y el caso de macro se limiten a su uso dentro de interfaces API extranjeras. [35]
Perl toma algunas señales de su herencia C para convenciones. Las variables de ámbito local y los nombres de subrutinas están en minúsculas con guiones bajos infijos. Las subrutinas y variables que deben tratarse como privadas tienen el prefijo de guión bajo. Las variables del paquete están escritas en mayúsculas y minúsculas. Las constantes declaradas están todas en mayúsculas. Los nombres de los paquetes están en mayúsculas y minúsculas, excepto pragmata, por ejemplo, stricty mro, que están 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 las clases 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 Ruby recomiendan UpperCamelCasenombres de clases, CAPITALIZED_WITH_UNDERSCORESconstantes y snake_caseotros nombres.
En Python, si un nombre pretende ser " privado ", tiene el prefijo uno o dos guiones bajos. Las variables privadas se aplican en Python sólo por convención. Los nombres también pueden tener como sufijo un guión bajo para evitar conflictos con las palabras clave de Python. El prefijo con guiones bajos dobles cambia el comportamiento en las clases con respecto a la alteración de nombres . Los prefijos y sufijos con guiones bajos dobles, los llamados métodos "dunder" ("doble debajo") en Python, están reservados 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 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óstrofe '(o comillas simples) dentro de un identificador (pero no dos seguidos), siempre que vaya seguido de un carácter alfabético. Por lo tanto, los programadores de Raku suelen utilizar mayúsculas y minúsculas kebab en sus identificadores; por ejemplo, fish-foody don't-do-thatson identificadores válidos.[42]
Rust recomienda UpperCamelCasepara alias de tipos y nombres de estructuras, rasgos, enumeraciones y variantes de enumeraciones, SCREAMING_SNAKE_CASEpara constantes o estáticas y snake_casepara nombres de miembros de variables, funciones y estructuras. [43]
Swift ha cambiado sus convenciones de nomenclatura con cada lanzamiento individual. Sin embargo, una actualización importante con Swift 3.0 estabilizó las convenciones de nomenclatura para lowerCamelCasetodas las variables y declaraciones de funciones. Las constantes generalmente se definen 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 declaración y nomenclatura de API en todas las API de terceros. [44]