Convención de nombres (programación)

En Programación, una convención de nombres es un conjunto de reglas para la elección de la secuencia de caracteres que se utilice para identificadores que denoten variables, tipos, funciones y otras entidades en el código fuente y la documentación.

Algunas de las razones para utilizar una convención de nombres (en lugar de permitir a los programadores elegir cualquier secuencia de caracteres) son:

• Reducir el esfuerzo necesario para leer y entender el código fuente.^[1]​
• Mejorar la apariencia del código fuente (por ejemplo, al no permitir nombres excesivamente largos o abreviaturas poco claros).

La elección de las convenciones de nombres puede ser un problema de enorme polémica, donde los partidarios de cada convención consideran la suya como la mejor y las demás inferiores. Coloquialmente, se dice que es una cuestión de dogma.^[2]​ Muchas empresas también han establecido su propio conjunto de convenciones para satisfacer mejor sus intereses.

Beneficios potenciales

Algunos de los beneficios potenciales que se pueden obtener mediante la adopción de una convención de nombres incluyen los siguientes:

• Proporcionar información adicional (es decir, los metadatos) sobre el uso que se hace de un identificador.
• Ayudar a formalizar las expectativas y promover la Consistencia dentro de un equipo de desarrollo.
• Permitir el uso de refactorización automatizado o buscar y reemplazar herramientas con un potencial mínimo para el error.
• Mejorar la claridad en los casos de ambigüedad potencial.
• Mejorar la apariencia estética y profesional de producto de trabajo (por ejemplo, al no permitir nombres excesivamente largos, nombres cómicos o las abreviaturas).
• Ayudar a evitar "conflictos de nombres" que podrían ocurrir cuando se combina el producto del trabajo de diferentes organizaciones (véase también: espacios de nombres).
• Proporcionar datos significativos que se utilizarán en los traspasos de proyectos que requieren la presentación de código fuente del programa y toda la documentación pertinente.
• Proporcionar una mejor comprensión en el caso de la reutilización de código después de un largo intervalo de tiempo.

Desafíos

La elección de las convenciones de nombres (y la medida en que se hacen cumplir) es a menudo un tema polémico, donde distintas convenciones cuentan con partidarios convencidos de que su convención es la mejor y las demás son inferiores. Además, incluso dada una convención de nombres bien definida y establecida en una organización, en algunos casos no se cumple de forma sistemática, lo cual contribuye a una mayor incoherencia y confusión. Estos retos pueden exacerbarse si las reglas de la convención de nombres no tienen coherencia interna o son arbitrarias, difíciles de recordar, o percibidas de otra manera como más perjudiciales que beneficiosas.

El valor del negocio

Aunque en gran parte oculto a la vista de la mayoría de los usuarios de negocios, identificadores bien escogidos hacen que sea mucho más fácil para las siguientes generaciones de analistas y desarrolladores para entender lo que hace el sistema y cómo solucionarlo o ampliar el código fuente para las nuevas necesidades del negocio.

Por ejemplo, aunque la siguiente:

 a = b * c; 

Es sintácticamente correcta, su propósito no es evidente. Contraste esto con:

 salario = horas_trabajadas * salario_por_hora; 

Lo que implica la intención y el significado del código fuente, por lo menos para aquellos que están familiarizados con el contexto subyacente de la aplicación.

Elementos comunes

Las reglas exactas de una convención de nombres dependen del contexto en que se emplean. Sin embargo, hay varios elementos comunes a todos los convenios de denominación de uso común hoy en día.

Longitud de identificadores

Un elemento fundamental de todas las convenciones de nombres son las reglas relacionadas con la longitud de los identificadores (es decir, el número finito de caracteres individuales permitidos en un identificador). Algunas reglas fijan una longitud máxima, mientras que otras especifican heurísticas o directrices menos precisos.

Las reglas que fijan la longitud de identificadores se impugnan habitualmente en la práctica, y están sujetas a abundante debate académico.

Algunas consideraciones:

• Los identificadores más cortos cuentan con la ventaja de ser más fáciles de escribir.
• Los identificadores extremadamente cortos (por ejemplo, 'i' o 'j') son muy difíciles de distinguir de forma única mediante herramientas automáticas de búsqueda y reemplazo.
• Los identificadores más largos pueden preferirse porque los identificadores más cortos no pueden codificar suficiente información o resultan demasiado crípticos.
• Los identificadores más largos pueden estorbar a la vista.

Es un tema de investigación abierto si algunos programadores prefieren identificadores más cortos porque son más fáciles de escribir o de inventar que los identificadores más largos, o porque en muchas situaciones un identificador más largo estorba el código visible y no proporciona un beneficio adicional aparente.

La brevedad en la programación puede atribuirse a:

• Primeros enlazadores que requerían nombres de variables con un máximo de 6 caracteres para ahorrar memoria. Un "avance" más adelante permitió aumentar la longitud de los nombres de variables para facilitar la comprensión humana, pero donde sólo los primeros caracteres eran significativos. En algunas versiones de BASIC como TRS-80 Nivel Básico 2, estaban permitidos los nombres largos, pero solo las dos primeras letras eran significativas. Esta característica permitía un comportamiento erróneo que podía ser difícil de depurar, por ejemplo, cuando se utilizaban dos variables que empezaban por las mismas letras (como SUMA y SUPLEMENTO), pero estaban pensadas para ser tratadas de forma diferente.
• editores de código fuente que carecían de una función de autocompletado.
• Monitores de baja resolución con una longitud de línea limitada, por ejemplo, a sólo 80 caracteres.
• Que gran parte de la informática provenga de las matemáticas, donde los nombres de variables constan, tradicionalmente, de una sola letra.

Mayúsculas, minúsculas y números

Algunas convenciones de nombres fijan el uso de mayúsculas o minúsculas. Otras convenciones no hacen esta restricción, pero sí atribuyen a los identificadores una interpretación bien definida basada en el uso de mayúsculas o minúsculas. Algunas convenciones de nombres especifican si se pueden utilizar caracteres alfabéticos, numéricos o alfanuméricos, y si es así, en qué secuencia.

Identificadores de varias palabras

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 nombres especifican las reglas para el tratamiento de identificadores "compuestos" que contienen más de una palabra.

Como en la mayoría de los lenguajes de programación no están permitidos los espacios en blanco en los identificadores, y la simple concatenación puede hacer que un nombre largo que comprende varias palabras resulte confuso, se necesita un método de delimitación de cada palabra (para que los lectores posteriores puedan interpretar más fácilmente qué caracteres pertenecen a cada palabra).

Palabras separadas por delimitadores

Un enfoque consiste en delimitar palabras separadas con un carácter no alfanumérico. Los dos caracteres más usados para este fin son el guion ("-") y el guion bajo ("_"); por ejemplo, el nombre de dos palabras "dos palabras" se representaría como "dos-palabras" o "dos_palabras". Casi todos los programadores que escriben en COBOL, Forth y Lisp emplean el guion, que también es común en los nombres de selectores en las hojas de estilo en cascada. La mayoría de los demás lenguajes de programación (por ejemplo, los de las familias C y Pascal) se reservan el guion para su uso como el operador infijo de resta, por lo que no está disponible para su uso en los identificadores y por lo tanto se utilizan las barras bajas en su lugar, como ocurre en Python.

Palabras separadas por mayúsculas

Otro enfoque consiste en indicar los límites de palabra utilizando capitalización medial (también llamado "CamelCase" y muchos otros nombres), de forma que "dos palabras" pasa a ser "dosPalabras" o "DosPalabras". Esta convención se utiliza habitualmente en Java, C# y Visual Basic. El tratamiento de las siglas en identificadores (por ejemplo, XML y HTTP en XMLHttpRequest) puede variar. En algunos convenios, se pasan a minúsculas (en este caso, XmlHttpRequest) para facilitar la mecanografía y la lectura, mientras que en otros se dejan en mayúsculas (XMLHTTPRequest) para mayor exactitud. Una opción menos popular es ampliar todas las siglas (ExtensibleMarkupLanguageHyperTextTransferProtocolRequest).

Metadatos y convenciones híbridas

Algunas convenciones de nombres representan normas o requisitos que van más allá de los requisitos de un proyecto específico o dominio del problema, y en lugar de reflejar un mayor conjunto general de principios definidos por la arquitectura de software, lenguaje de programación subyacente u otro tipo de metodología entre proyectos.

Notación húngara

Tal vez la más conocida es la notación húngara, que codifica ya sea el propósito ("Aplicaciones de Hungría") o el tipo ("Sistemas de Hungría") de una variable en su nombre.^[3]​ Por ejemplo, el prefijo "sz" para el szName variable indica que la variable es una cadena de cero (es decir null-) terminado.

Notación posicional

Un estilo utilizado para muy cortas (8 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 proceso en particular, y el 01 un número de secuencia.

Este tipo de convenciones se encuentra todavía en uso activo en mainframes que dependen de JCL y también se ve en los 8,3 (máximo 8 caracteres con periodo separador seguido de 3 caracteres tipo de archivo) estilo MS-DOS.

Esquema de palabra compuesta (del lenguaje)

Uno de los sistemas de convenciones publicadas primeros fue de IBM "del lenguaje" documentada en un IMS (Information Management System) 1980 Manual ^{[cita requerida]}.

Se detalla el esquema de palabra PRIME-MODIFIER-CLASS, que consistía en nombres como "MEM-ACT-NO" para indicar "número de cuenta del cliente."

PRIME palabras estaban destinadas a indicar las principales "entidades" de interés para un sistema.

Palabras MODIFIER fueron utilizados para el refinamiento adicional, la cualificación y la legibilidad.

Palabras CLASS ideal sería una lista muy corta de los tipos de datos relevantes para una aplicación particular. Clase de palabras comunes pueden ser: NO (número), ID (identificador), TXT (texto), AMT (cantidad), CANT (cantidad), FL (bandera), CD (código), W (trabajo) y así sucesivamente. En la práctica, la clase de palabras disponibles sería una lista de menos de dos docenas de términos.

Palabras CLASS, normalmente situados a la derecha (sufijo), sirven el mismo propósito como prefijos de notación húngara.

El propósito de la clase de palabras, además de la consistencia, era especificar al programador el tipo de datos de un campo de datos particular. Antes de la aceptación de BOOLEAN (dos valores únicos) Campos, FL (bandera) indicarían un campo con sólo dos valores posibles.

Convenciones específicas del lenguaje

ActionScript

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

Ada

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

C y C++

En C y C++, las palabras clave e identificadores de la biblioteca estándar son 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 prueba de la función si un carácter es alfanumérico), mientras que la biblioteca estándar C++ menudo utiliza un guion como separador de palabra (por ejemplo out_of_range ). Identificadores representan macros son, por convención, escrito usando sólo letras mayúsculas y guiones bajos (esto está relacionado con la convención en muchos lenguajes de programación de la utilización de todo mayúsculas identificadores de constantes). Nombres que contienen doble guion o que comienzan con un guion bajo y una letra mayúscula se reservan para la implementación (compilador, biblioteca estándar) y no deben ser usados (por ejemplo reserved__ o _Reserved ).^[5]​^[6]​ Esto es superficialmente similar a afilar, pero la semántica difiere: los subrayados son parte del valor del identificador, en lugar de ser carácter delimitador (como se afila): el valor de __foo es __foo (que está reservado), no foo (pero en un espacio de nombres diferente).

Java

En Java, las convenciones de nombres para los identificadores se han establecido y propuesto por varias comunidades de Java como Sun Microsystems,^[7]​ Netscape,^[8]​ AmbySoft,^[9]​ etc. Una muestra de las convenciones de nomenclatura establecidas por Sun Microsystems se enumeran a continuación, donde un nombre en "CamelCase" es un compuesto de un número de palabras unidas sin espacios, con letra inicial de cada palabra en mayúsculas - por ejemplo "CamelCase".

Tipo de identificador	Reglas para nombrar	Ejemplos
Clases	Los nombres de clase deben ser sustantivos en Upper CamelCase, con la primera letra de cada palabra en mayúscula. Use palabras completas - evitar acrónimos y abreviaturas (a menos que la abreviatura es mucho más extendido que el de la forma larga, como la dirección URL o HTML).	class Raster; class ImageSprite;
Métodos	Los métodos deben ser verbos en lower CamelCase o un conjunto de varias palabras que comienza con un verbo en minúsculas; es decir, con la primera letra en minúscula y la primera letra de las palabras siguientes en mayúsculas.	run(); runFast(); getBackground();
Variables	Las variables locales, variables de instancia y variables de clase también se escriben en lower CamelCase. Los nombres de variable no deben comenzar con los caracteres guion bajo ( _ ) o el signo de dólar ( $ ), aunque ambos se admiten. Esto contrasta con otras convenciones de codificación que establecen que los guiones deben ser usados como prefijo todas las variables de instancia. Los nombres de variables deben ser cortos pero significativos. La elección de un nombre de variable debe ser mnemónico - es decir, diseñado para indicar al observador casual la intención de su uso. Se deben evitar los nombres de variables de un solo carácter excepto para las variables temporales "usar y tirar". Los nombres comunes de las variables temporales son i, j, k, m, y n, para enteros; c, d, y e para los caracteres.	int i; char c; float myWidth;
Constantes	Los nombres de las constantes se deben escribir en mayúsculas separadas por guiones bajos. Los nombres de constantes pueden contener dígitos, pero no como primer carácter.	final static int MAX_PARTICIPANTS = 10;

Compiladores Java no hacen cumplir estas reglas, pero no seguir las mismas pueden dar lugar a confusión y código erróneo. Por ejemplo, widget.expand() y Widget.expand() implica significativamente diferentes comportamientos: widget.expand() implica una invocación al método expand() en una instancia con nombre widget, mientras que Widget.expand() implica una invocación al método estático expand() en la clase Widget.

Un estilo de programación Java ampliamente utilizado dicta que UpperCamelCase ser utilizado para clases y lowerCamelCase utilizarse para instancias y métodos.^[7]​ Reconociendo este uso, algunos IDE como Eclipse, implementar atajos basados en CamelCase. Por ejemplo, en el contenido de Eclipse función de asistencia, escribiendo únicamente las letras mayúsculas de una palabra CamelCase sugerirá ningún nombre de la clase a juego o método (por ejemplo, al escribir "NPE" y activando ayuda de contenido podría sugerir NullPointerException ).

Siglas de tres o más letras se camelCase en lugar de mayúsculas (por ejemplo, parseDbmXmlFromIPAddress lugar de parseDBMXMLFromIPAddress ). También se puede establecer el límite en dos o más letras (por ejemplo parseDbmXmlFromIpAddress ).

JavaScript

Las bibliotecas incorporadas de JavaScript utilizan las mismas convenciones de nomenclatura como Java. Las clases utilizan camel case superior (RegExp, TypeError, XMLHttpRequest, DOMObject) y métodos utilizar lower camel case (getElementById, getElementsByTagNameNS, createCDATASection). Con el fin de ser consistentes desarrolladores más de JavaScript siguen estas convenciones. ^{[cita requerida]} Ver también: convenciones de Douglas Crockford

Lisp

La práctica común en la mayoría de los dialectos de Lisp es utilizar guiones para separar las palabras en los identificadores, como en with-open-file y make-hash-table. Nombres de variables globales convencionalmente comienzan y terminan con asteriscos: *map-walls*. Nombres Constantes están marcadas por signos de suma: +map-size+.^[10]​

.NET

Microsoft NET recomienda UpperCamelCase para la mayoría de los identificadores. (LowerCamelCase se recomienda para los parámetros y variables) y es una convención común para los lenguajes.NET.^[11]​ Microsoft recomienda también que no se utilicen pistas de tipo prefijo (también conocido como notación húngara).^[12]​ En lugar de utilizar la notación húngara se recomienda terminar el identificador con el nombre de la clase base; LoginButton en lugar de BtnLogin.^[13]​

Objective-C

Objective-C tiene un estilo común de codificación que tiene sus raíces en Apple ejemplo de código.

Entidades de primer nivel, incluyendo clases, protocolos, categorías, así como construcciones de C que se utilizan en los programas de Objective-C como variables y funciones globales, están en UpperCamelCase con una breve mayúsculas-espacio de nombres que denota prefijo, como NSString, UIAppDelegate, NSApp o CGRectMake. Las constantes pueden ser opcionalmente precedidos por una letra minúscula "k" como kCFBooleanTrue.

variables de instancia de un uso objeto lowerCamelCase precedidos por un guion, como _delegate y _tableView.

Nombres de los métodos utilizan múltiples partes lowerCamelCase separados por dos puntos que delimitan argumentos, como: aplicación: didFinishLaunchingWithOptions:, stringWithFormat: y IsRunning.

Perl

Perl toma algunas señales de su patrimonio C para convenciones. A nivel local ámbito de variables y nombres de subrutinas son minúsculas con guiones bajos infijos. Subrutinas y variables con la intención de ser tratado como privado están prefijadas con un guion bajo. Las variables del paquete son título entubado. Constantes declaradas son mayúsculas. Los nombres de paquetes son camel case-exceptuando prágmata por ejemplo, strict y mro -que son minúsculas. ^[14]​ ^[15]​

Python y Ruby

Python y Ruby tanto recomiendan UpperCamelCase para nombres de clases, CAPITALIZED_WITH_UNDERSCORES para las constantes y lowercase_separated_by_underscores para otros nombres. En Python, si un nombre está destinado a ser "privado", que está precedido de un guion bajo.^[16]​

Referencias

1. Derek M. Jones "nombres operando la influencia del operador decisiones de precedencia" Un experimento que investiga el efecto de los nombres de variables de selección de prioridad de operador.
2. Raymond, Eric S. (1 de octubre de 2004). «religious issues». The Jargon File (versión 4.4.8 edición). Consultado el 7 de noviembre de 2011. 
3. http://www.joelonsoftware.com/articles/Wrong.html
4. http://www.adaic.org/resources/add_content/docs/95style/html/sec_3/3-2-1.html
5. «ISO/IEC 9899:1999 Programming languages -- C». ISO. 
6. «ISO/IEC 14882:2011 Information technology -- Programming languages -- C++». ISO. 
7. "Convenciones de código para el lenguaje de programación Java", Sección 9: "Convenciones de nomenclatura"
8. "SOFTWARE DE NETSCAPE Normas de codificación GUÍA PARA JAVA", Collab Software Codificación Guía de Normas para Java el 3 de marzo de 2009 en Wayback Machine.
9. "AmbySoft Inc. Estándares de Codificación para v17.01d Java"
10. http://www.gigamonkeys.com/book/variables.html
11. Microsoft NET Framework Estilos de Capitalización
12. Guía de NET Framework Developer - Convenciones de nomenclatura general
13. [Framework Instrucciones de diseño, Krzysztof Cwalina, Brad Abrams Página 62]
14. . Archivado desde el original el 26 de junio de 2013. Consultado el 7 de septiembre de 2014. 
15. «perlmodlib - constructing new Perl modules and finding existing ones». 
16. [Guía de Estilo https://www.python.org/dev/peps/pep-0008/ de código Python PEP8]

Enlaces externos

• - Promueve la onomástica, el estudio de los nombres y las prácticas de asignación de nombres, tanto en Estados Unidos como en el extranjero.
• Codificación-guidelines.com tiene una de 100 páginas pdf que usa la lingüística y la psicología para intentar un análisis de costo / beneficio de las cuestiones de nomenclatura de identificadores
• La aplicación de etiquetado o las convenciones de nomenclatura unificadas en la ingeniería de la ontología ayudarán a armonizar la apariencia y aumentar la robustez de las unidades de representación ontológica, como nombres de clases y relaciones dentro del conjunto ortogonal de ontologías OBO Foundry.

•   Datos: Q461984