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 usar una convención de nomenclatura (en lugar de permitir que los programadores elijan cualquier secuencia de caracteres) incluyen las siguientes:
- 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 nomenclatura.
- Permitir que las herramientas de revisión de la calidad del código centren sus informes principalmente en cuestiones importantes distintas de las preferencias de estilo y sintaxis.
La elección de las convenciones de nomenclatura puede ser un tema enormemente controvertido, ya que los partidarios de cada uno consideran que los suyos son los mejores y los demás inferiores. Coloquialmente, se dice que esto es una cuestión de dogma . [2] Muchas empresas también han establecido su propio conjunto de convenciones.
Beneficios potenciales
Algunos de los beneficios potenciales que se pueden obtener al adoptar una convención de nomenclatura incluyen los siguientes:
- 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;
- para permitir el uso de refactorización automatizada o buscar y reemplazar herramientas 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, al rechazar nombres demasiado largos, nombres cómicos o "lindos" o abreviaturas);
- para ayudar a evitar "colisiones de nombres" que pueden ocurrir cuando se combina el producto del trabajo de diferentes organizaciones (ver también: espacios de nombres );
- proporcionar datos significativos para su uso en traspasos de proyectos que requieren la presentación del código fuente del programa y toda la documentación pertinente;
- para proporcionar una mejor comprensión en caso de reutilización del código después de un largo intervalo de tiempo.
Desafíos
La elección de las convenciones de nomenclatura (y la medida en que se hacen cumplir) es a menudo un tema polémico, ya que los partidarios sostienen que su punto de vista es el mejor y los demás, inferiores. Además, incluso con convenciones de nomenclatura conocidas y bien definidas, algunas organizaciones pueden fallar en adherirse a ellas de manera consistente, lo que genera inconsistencia y confusión. Estos desafíos pueden exacerbarse si las reglas de la convención de nomenclatura son internamente inconsistentes, arbitrarias, difíciles de recordar o percibidas como más onerosas que beneficiosas.
Legibilidad
Los identificadores bien elegidos facilitan significativamente a los desarrolladores y analistas comprender lo que está haciendo el sistema y cómo corregir o extender el código fuente para solicitar 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 * tarifa_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]
Elementos comunes
Las reglas exactas de una convención de nomenclatura dependen del contexto en el que se emplean. Sin embargo, existen varios elementos comunes que influyen en la mayoría, si no en todas, las convenciones de nomenclatura de uso común en la actualidad.
Longitud de identificadores
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 impugnan habitualmente en la práctica y están sujetas a mucho debate académico.
Algunas consideraciones:
- Los identificadores más cortos pueden ser preferidos como más convenientes, porque son más fáciles de escribir (aunque muchos IDE y editores de texto proporcionan compleción de texto, lo que mitiga esto)
- 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 )
- Los identificadores más largos pueden ser preferidos porque los identificadores cortos no pueden codificar suficiente información o parecen demasiado crípticos.
- los identificadores más largos pueden ser desfavorecidos debido al desorden visual
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:
- los primeros enlazadores que requerían que los nombres de las variables estuvieran restringidos a 6 caracteres para ahorrar memoria. Un "avance" posterior permitió que los nombres de variables más largos se usaran para la comprensión humana, pero donde solo los primeros caracteres eran significativos. En algunas versiones de BASIC , como TRS-80 Level 2 Basic, se permitían nombres largos, pero solo las dos primeras letras eran significativas. Esta característica permitía comportamientos erróneos que podrían ser difíciles de depurar, por ejemplo, cuando se usaban nombres como "VALOR" e "IVA" con la intención de que fueran distintos.
- los primeros editores de código fuente que carecen de autocompletar
- los primeros monitores de baja resolución con una longitud de línea limitada (por ejemplo, solo 80 caracteres)
- gran parte de las ciencias de la computación se originan en las matemáticas, donde los nombres de las variables son tradicionalmente solo una letra
Caja de letras y números
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 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.
Identificadores de varias palabras
Una recomendación común es "Utilice 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 tempranos, notablemente 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 se usa a veces, como en los mypackage
nombres de paquetes de Java, [4] aunque la legibilidad sufre para términos más largos, por lo que generalmente se usa alguna forma de separación.
Palabras separadas por delimitadores
Un enfoque consiste en delimitar palabras separadas con un carácter no alfanumérico . Los dos caracteres que se utilizan comúnmente 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 el caso 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 algo de 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 , utilizaban el guión para el operador infijo de resta y no deseaban requerir espacios a su alrededor (como lenguajes de forma libre ), lo que impedía su uso en identificadores. Una alternativa es usar 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 caso de serpiente . Los guiones bajos con mayúsculas, como en UPPER_CASE, se usan comúnmente para las macros del preprocesador de C , por lo que se conocen como MACRO_CASE, y para las variables de entorno en Unix, como BASH_VERSION en bash . A veces, esto se conoce con humor como SCREAMING_SNAKE_CASE.
Palabras separadas entre mayúsculas y minúsculas
Otro enfoque es indicar los límites de las palabras usando mayúsculas medial, llamado " camelCase ", "caso Pascal" y muchos otros nombres, traduciendo 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 XmlHttpRequest
. Ej. ) Para facilitar la escritura, la legibilidad y la facilidad de segmentación , mientras que otros los dejan en mayúsculas (p XMLHTTPRequest
. Ej. ) Para mayor precisión.
Ejemplos de formatos de identificadores de varias palabras
Formateo | Nombre (s) |
---|---|
twowords | caja plana [13] [14] |
TWOWORDS | caja superior plana [13] |
twoWords | (inferior) camelCase , dromedaryCase |
TwoWords | PascalCase, UpperCamelCase, StudlyCase [15] |
two_words | estuche_serpiente , estuche_bachero |
TWO_WORDS | SCREAMING_SNAKE_CASE , MACRO_CASE, CONSTANT_CASE |
two_Words | camel_Snake_Case |
Two_Words | Pascal_Snake_Case |
two-words | estuche para kebab, estuche para tablero, estuche lisp |
two|words | doner | caso [ cita requerida ] |
TWO-WORDS | ESTUCHE-TREN, ESTUCHE COBOL, ESTUCHE-KEBAB-GRITADOR |
Two-Words | Train-Case, [13] HTTP-Header-Case [16] |
Metadatos y convenciones híbridas
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 de proyectos cruzados.
Notación húngara
Quizás la más conocida sea la notación húngara , que codifica el propósito ("Aplicaciones húngaro") o el tipo ("Sistemas húngaro") 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.
Notación posicional
Un estilo utilizado para 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 de proceso en particular y 01 un número de secuencia.
Este tipo de convención todavía está en uso activo en mainframes que dependen de JCL y también se ve en el estilo de MS-DOS 8.3 (máximo ocho caracteres con separador de punto seguido de un tipo de archivo de tres caracteres).
Esquema de palabras compuestas (OF Language)
El "lenguaje OF" de IBM se documentó 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 las principales "entidades" de interés para un sistema.
Las palabras MODIFICADORES se utilizaron para un refinamiento, calificación y legibilidad adicionales.
Idealmente, las palabras CLASS serían una lista muy corta de tipos de datos relevantes para una aplicación en particular. Las palabras CLASS comunes pueden ser: NO (número), ID (identificador), TXT (texto), AMT (cantidad), QTY (cantidad), FL (bandera), CD (código), W (trabajo) y así sucesivamente. 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 los campos BOOLEAN (solo dos valores), FL (bandera) indicaría un campo con solo dos valores posibles.
Convenciones específicas del idioma
ActionScript
Las mejores prácticas y convenciones de codificación de Adobe sugieren estándares de nomenclatura para ActionScript que son en su mayoría consistentes con los de ECMAScript . [ cita requerida ] El estilo de los identificadores es similar al de Java .
Ada
En Ada , el único estilo de identificadores recomendado es Mixed_Case_With_Underscores
. [18]
APL
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 usó letras subrayadas, entonces se usaría la barra delta (⍙) en su lugar.
C y C ++
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, isalnum
para una función que prueba si un carácter es un número), 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 , por convención, se escriben 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 subrayado o que comienzan con un subrayado y una letra mayúscula están reservados para la implementación ( compilador , biblioteca estándar ) y no deben usarse (por ejemplo, __reserved
o _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 estar entre comillas (como es stropping): el valor de __foo
es __foo
(que está reservado), no foo
(pero en un espacio de nombres diferente).
C#
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 hace cumplir las convenciones.
Las pautas de Microsoft recomiendan el uso exclusivo de PascalCase y camelCase , y este último se usa solo para nombres de parámetros de métodos y nombres de variables locales de métodos (incluidos los const
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 están en 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 un PascalCaseinterface
sea precedido por la letra I mayúscula , como en .IEnumerable
Las directrices de Microsoft para la denominación de los campos son específicos para static
, public
y protected
campos; los campos que no lo son static
y que tienen otros niveles de accesibilidad (como internal
y private
) no están explícitamente cubiertos por las pautas. [22] La práctica más común es usar PascalCase para los nombres de todos los campos, excepto aquellos que son private
(y ninguno const
ni static
), que son nombres que usan camelCase precedidos por un guión bajo simple; por ejemplo _totalCount
,.
Cualquier nombre de identificador puede tener como prefijo el símbolo comercial-en ( @ ), sin ningún cambio de significado. Es decir, ambos factor
y se @factor
refieren al mismo objeto. Por convención, este prefijo solo se usa en los casos en que el identificador sería una palabra clave reservada (como for
y while
), que no puede usarse como un identificador sin el prefijo, o una palabra clave contextual (como from
y where
), en la que En los casos en que el prefijo no es estrictamente necesario (al menos no en su declaración; por ejemplo, aunque la declaración dynamic dynamic;
es válida, esto típicamente se consideraría como dynamic @dynamic;
una indicación inmediata al lector de que este último es un nombre de variable).
Ir
En Go , la convención es utilizar MixedCaps
o en mixedCaps
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 los paquetes externos. Convertir la primera letra en mayúscula exporta ese fragmento de código, mientras que en minúsculas solo se puede usar dentro del ámbito actual. [23]
Java
En Java , varias comunidades Java como Sun Microsystems, [24] Netscape, [25] AmbySoft, [26] han establecido y sugerido convenciones de nomenclatura para los identificadores , etc. A continuación se enumera una muestra de las convenciones de nomenclatura establecidas por Sun Microsystems, donde un nombre en " CamelCase " es uno que se compone de 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".
Tipo de identificador | Reglas para nombrar | Ejemplos de |
---|---|---|
Clases | Los nombres de las clases deben ser sustantivos , con la primera letra de cada palabra en mayúscula. Utilice palabras completas: evite los acrónimos y las abreviaturas (a menos que la abreviatura se utilice mucho más que la forma larga, como URL o HTML).UpperCamelCase |
|
Métodos | Los métodos deben ser verbos en o un nombre de varias palabras que comience con un verbo en minúsculas; es decir, con la primera letra en minúscula y las primeras letras de las palabras siguientes en mayúscula.lowerCamelCase |
|
Variables | Las variables locales, las variables de instancia y las variables de clase también se escriben en formato . Los nombres de las variables no deben comenzar con caracteres de subrayado ( ) o de signo de dólar ( ), aunque ambos están permitidos. Esto contrasta con otras convenciones de codificación que establecen que se deben usar guiones bajos para prefijar todas las variables de instancia.lowerCamelCase _ $ Los nombres de las variables deben ser cortos pero significativos. La elección de un nombre de variable debe ser nemotécnica , es decir, diseñada para indicar al observador casual la intención de su uso. Deben evitarse los nombres de variables de un carácter, excepto las variables temporales "desechables". Los nombres comunes para las variables temporales son i, j, k, myn para los números enteros; c, dye para los personajes. |
|
Constantes | Las constantes deben escribirse en mayúsculas separadas por guiones bajos. Los nombres constantes también pueden contener dígitos si corresponde, pero no como el primer carácter. |
|
Los compiladores de Java no hacen cumplir estas reglas, pero no seguirlas puede resultar en 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 nombrada 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 de Java ampliamente utilizado dicta que UpperCamelCase se use para clases y lowerCamelCase se use para instancias y métodos . [24] 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 solo las letras mayúsculas de una palabra de CamelCase sugerirá cualquier clase o nombre de método coincidente (por ejemplo, escribir "NPE" y activar la asistencia de contenido podría sugerir NullPointerException
).
Los iniciales de tres o más letras son CamelCase en lugar de mayúsculas (por ejemplo, en parseDbmXmlFromIPAddress
lugar de parseDBMXMLFromIPAddress
). También se puede establecer el límite en dos o más letras (p parseDbmXmlFromIpAddress
. Ej .).
JavaScript
Las bibliotecas JavaScript integradas utilizan las mismas convenciones de nomenclatura que Java. Los tipos de datos y las funciones de constructor usan mayúsculas y minúsculas ( RegExp , TypeError , XMLHttpRequest , DOMObject ) y los métodos usan minúsculas camel ( getElementById , getElementsByTagNameNS , createCDATASection ). Para ser coherentes, la mayoría de los desarrolladores de JavaScript siguen estas convenciones. [27] Ver también: Convenciones de Douglas Crockford
Ceceo
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-file
y make-hash-table
. Nombres de las variables dinámicas convencionalmente empiezan y terminan con asteriscos: *map-walls*
. Constantes nombres están marcadas por signos de suma: +map-size+
. [28] [29]
.NETO
Microsoft .NET recomienda UpperCamelCase , también conocido como PascalCase , para la mayoría de los identificadores. ( Se recomienda lowerCamelCase para parámetros y variables ) y es una convención compartida para los lenguajes .NET. [30] Microsoft recomienda además que no se utilicen pistas de prefijo de tipo (también conocidas como notación húngara ). [31] En lugar de usar la notación húngara, se recomienda terminar el nombre con el nombre de la clase base; LoginButton
en lugar de BtnLogin
. [32]
C objetivo
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, así como las construcciones de C que se utilizan en los programas de Objective-C como las variables y funciones globales, están en UpperCamelCase con un prefijo corto en mayúsculas que denota un espacio de nombres, como NSString , UIAppDelegate , NSApp o CGRectMake . Opcionalmente, las constantes pueden ir precedidas de una letra minúscula "k" como kCFBooleanTrue .
Las variables de instancia de un objeto usan lowerCamelCase prefijado con un guión bajo, como _delegate y _tableView .
Los nombres de método usan múltiples partes lowerCamelCase separados por dos puntos que los argumentos delimitar, como: aplicación: didFinishLaunchingWithOptions: , stringWithFormat: y isRunning .
Pascal, Modula-2 y Oberon
Idiomas Wirthian Pascal, Modula-2 y Oberon usan generalmente Capitalized
o UpperCamelCase
identificadores de programas, módulos, constantes, tipos y procedimientos, y el lowercase
o los lowerCamelCase
identificadores de las constantes matemáticas, variables, parámetros formales y funciones. [33] Si bien algunos dialectos admiten el subrayado y los signos de dólar en los identificadores, es más probable que el uso de mayúsculas y minúsculas y mayúsculas se limite al uso en interfaces API externas. [34]
Perl
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 destinadas a ser tratadas como privadas tienen el prefijo de subrayado. Las variables del paquete están en mayúsculas y minúsculas Las constantes declaradas son todas mayúsculas. Los nombres de los paquetes son en mayúsculas, excepto pragmata, por ejemplo, strict
y , mro
que están en minúsculas. [35] [36]
PHP
Las recomendaciones de PHP están contenidas en PSR-1 ( Recomendación estándar de PHP 1) y PSR-12. [37] 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 los métodos deben estar en camelCase. [38]
Python y Ruby
Python y Ruby recomiendan UpperCamelCase
para nombres de clases, CAPITALIZED_WITH_UNDERSCORES
constantes y lowercase_separated_by_underscores
otros nombres.
En Python, si un nombre está destinado a ser " privado ", se le antepone un guión bajo. Las variables privadas se aplican en Python solo por convención. Los nombres también pueden tener un sufijo de subrayado para evitar conflictos con las palabras clave de Python. El prefijo con doble subrayado cambia el comportamiento en las clases con respecto a la alteración de nombres . Los prefijos y sufijos con guiones bajos dobles están reservados para los "nombres mágicos" que cumplen un comportamiento especial en los objetos de Python. [39]
R
Si bien no existe una guía de estilo oficial para R , la guía de estilo tidyverse de R-guru Hadley Wickham establece el estándar para la mayoría de los usuarios. [40] Esta guía recomienda evitar los caracteres especiales en los nombres de los archivos y usar solo números, letras y guiones bajos para los nombres de variables y funciones, por ejemplo, fit_models.R.
Raku
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 esté seguido de un carácter alfabético. Por lo tanto, los programadores de Raku a menudo usan mayúsculas y minúsculas en sus identificadores; por ejemplo, fish-food
y don't-do-that
son identificadores válidos. [41]
Oxido
Rust recomienda UpperCamelCase
para alias de tipo y nombres de variantes de estructura, rasgo, enumeración y enumeración, SCREAMING_SNAKE_CASE
para constantes o estáticas y snake_case
para nombres de miembros de estructura, función y variable. [42]
Rápido
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 lowerCamelCase
todas 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 clase y otros tipos de objetos son UpperCamelCase
.
A partir de Swift 3.0, se han establecido pautas claras de nomenclatura para el lenguaje en un esfuerzo por estandarizar las convenciones de nomenclatura y declaración de API en todas las API de terceros. [43]
Ver también
- Categoría: convenciones de nomenclatura
- Checkstyle
- Convenciones de codificación
- Lista de herramientas para el análisis de código estático
- Espacio de nombres
- Convenio de denominación
- Sigil (programación de computadoras)
- Sintaxis (lenguajes de programación)
Referencias
- ^ Derek M. Jones "Los nombres de los operandos influyen en las decisiones de precedencia del operador" Un experimento que investiga el efecto de los nombres de las variables en la selección de la precedencia del operador
- ^ Raymond, Eric S. (1 de octubre de 2004). "cuestiones religiosas" . El archivo de jerga (versión 4.4.8 ed.) . Consultado el 7 de noviembre de 2011 .
- ^ Binkley, Dave; Davis, Marcia (2009). "A CamelCase o Under_score" (PDF) . 2009 IEEE 17th International Conference on Program Comprehension (17): 158–167. doi : 10.1109 / ICPC.2009.5090039 .
- ^ Nombrar un paquete
- ^ "Referencia CSS" . Red de desarrolladores de Mozilla . Consultado el 18 de junio de 2016 .
- ^ "StackOverflow - ¿Cuál es el nombre de snake_case con guiones?" .
- ^ "Programadores: si esto es camelCase, ¿qué es esto?" .
- ^ "Camel_SNAKE-kebab" . Septiembre de 2019.
- ^ SubrayadoVersusCapitalAndLowerCaseVariableNaming
- ^ jwfearn (5 de septiembre de 2012). "Revisiones a la respuesta de jwfearn a ¿Cuál es el nombre de las mayúsculas y minúsculas separados por guiones?" .
- ^ Living Clojure (2015), por Carin Meier, p. 91
- ^ lodash: kebabCase
- ^ a b c "naming - ¿Cuáles son los diferentes tipos de casos?" . Desbordamiento de pila . Consultado el 16 de agosto de 2020 .
- ^ "Una breve lista de convenciones de nomenclatura de programación" . deanpugh.com . 20 de marzo de 2018 . Consultado el 16 de agosto de 2020 .
- ^ "PSR-1: Estándar de codificación básico - PHP-FIG" . www.php-fig.org . Consultado el 4 de septiembre de 2020 .
- ^ "kebab-camello-serpiente" . kebab-camello-serpiente . Consultado el 16 de agosto de 2020 .
- ^ "Hacer que el código incorrecto parezca incorrecto" . 11 de mayo de 2005.
- ^ http://www.adaic.org/resources/add_content/docs/95style/html/sec_3/3-2-1.html
- ^ "ISO / IEC 9899: 1999 Lenguajes de programación - C" . YO ASI.
- ^ "ISO / IEC 14882: 2011 Tecnología de la información - Lenguajes de programación - C ++" . YO ASI.
- ^ "Directrices de nomenclatura" . Microsoft.
- ^ "Nombres de los miembros de tipo" . Microsoft.
- ^ "Effective Go - el lenguaje de programación Go" .
- ^ a b "Convenciones de código para el lenguaje de programación Java", Sección 9: "Convenciones de nomenclatura"
- ^ "GUÍA DE ESTÁNDARES DE CODIFICACIÓN DE SOFTWARE DE NETSCAPE PARA JAVA", Guía de estándares de codificación de software de Collab para Java Archivado el 3 de marzo de 2009 en Wayback Machine
- ^ "Estándares de codificación de AmbySoft Inc. para Java v17.01d"
- ^ Morelli, Brandon (17 de noviembre de 2017). "5 guías de estilo de JavaScript, incluidos AirBnB, GitHub y Google" . codeburst.io . Consultado el 17 de agosto de 2018 .
- ^ "Variables" .
- ^ Convenciones de nomenclatura en CLiki
- ^ Estilos de capitalización de Microsoft .NET Framework
- ^ Guía del desarrollador de .NET Framework - Convenciones generales de nomenclatura
- ^ [Pautas de diseño del marco, Krzysztof Cwalina, Brad Abrams Página 62]
- ^ Convención de nombres de Modula-2
- ^ Identificadores de API externos en la convención de nombres Modula-2
- ^ "Guía de estilo Perl" .
- ^ "perlmodlib - construyendo nuevos módulos Perl y encontrando los existentes" .
- ^ "Recomendaciones de estándares PHP" .
- ^ https://www.php-fig.org/psr/psr-1/
- ^ Guía de estilo para el código Python PEP8
- ^ Guía de estilo para RCode
- ^ "Reglas generales de la sintaxis de Perl 6" .
- ^ "Convenciones de nomenclatura" . doc.rust-lang.org . Consultado el 4 de febrero de 2018 .
- ^ "Directrices de diseño de API de swift.org" .
enlaces externos
- American Name Society : promueve la onomástica , el estudio de los nombres y las prácticas de denominación, tanto en los Estados Unidos como en el extranjero.
- coding-guidelines.com tiene un pdf que utiliza lingüística y psicología para intentar un análisis de costo / beneficio de los problemas de nomenclatura de identificadores