Camel case (a veces estilizado autológicamente como camelCase o CamelCase , también conocido como camel caps o más formalmente como medial capitals ) es la práctica de escribir frases sin espacios ni puntuación y con palabras en mayúscula . El formato indica la primera palabra que comienza con cualquiera de las mayúsculas y luego las siguientes palabras que tienen una letra mayúscula inicial . Los ejemplos comunes incluyen YouTube , [1] PowerPoint , HarperCollins , FedEx , iPhone , eBay , [2] y LaGuardia . [3] Camel case se usa a menudo como una convención de nomenclatura en programación informática. También se usa a veces en nombres de usuario en línea como JohnSmith , y para hacer que los nombres de dominio de varias palabras sean más legibles, por ejemplo, en la promoción de EasyWidgetCompany.com . De hecho, WikiWikiWeb , un antecesor de Wikipedia, está escrito en camel case.
Los términos más específicos Pascal case y upper camel case se refieren a una frase unida donde la primera letra de cada palabra está en mayúscula, incluida la letra inicial de la primera palabra. De manera similar, el camel case minúscula (también conocido como dromedary case ) requiere una letra minúscula inicial. Algunas personas y organizaciones, en particular Microsoft , usan el término camel case solo para el camel case minúscula, designando Pascal case para el camel case mayúscula. [4] Algunos estilos de programación prefieren camel case con la primera letra en mayúscula, otros no. [5] [4] [6] Para mayor claridad, este artículo deja la definición de camel case ambigua con respecto a la capitalización y usa los términos más específicos cuando es necesario.
El estilo camel case se distingue de otros estilos: el estilo title case , que pone en mayúsculas todas las palabras pero conserva los espacios entre ellas; el estilo Tall Man , que utiliza mayúsculas para enfatizar las diferencias entre nombres de productos de apariencia similar, como predniSONE y predniSOLONE ; y el estilo snake case , que utiliza guiones bajos intercalados con letras minúsculas (a veces con la primera letra en mayúscula). En la guía de estilo Ada 95 se recomienda una combinación de snake case y camel case (identificadores Written_Like_This ) . [7]
La práctica tiene varios nombres, entre ellos:
La primera aparición conocida del término "InterCaps" en Usenet se produjo en una publicación alt.folklore.computersde Avi Rappoport en el grupo en abril de 1990. [22] El primer uso del nombre "Camel Case" se produjo en 1995, en una publicación de Newton Love. [23] Love ha dicho desde entonces: "Con la llegada de los lenguajes de programación que tenían este tipo de construcciones, la joroba del estilo me hizo llamarlo HumpyCase al principio, antes de decidirme por CamelCase. Había estado llamándolo CamelCase durante años... La cita anterior fue simplemente la primera vez que usé el nombre en USENET". [24]
El uso de mayúsculas medias como convención en la ortografía regular de textos cotidianos es poco común, pero se utiliza en algunos idiomas como solución a problemas particulares que surgen cuando se combinan dos palabras o segmentos.
En italiano, los pronombres pueden añadirse sufijos a los verbos, y debido a que la forma honorífica de los pronombres de segunda persona se escribe con mayúscula, esto puede producir una oración como non ho trovato il tempo di risponderLe ("No he encontrado tiempo para responderte", donde Le significa "a ti").
En alemán, la letra mayúscula intermedia I , llamada Binnen-I , se utiliza a veces en una palabra como StudentInnen ("estudiantes") para indicar que se hace referencia simultáneamente a Studenten ("estudiantes varones") y Studentinnen ("estudiantes mujeres"). Sin embargo, la capitalización en mitad de palabra no se ajusta a la ortografía alemana, salvo en nombres propios como McDonald ; el ejemplo anterior podría escribirse correctamente utilizando paréntesis como Student(inn)en , análogo a "congress(wo)men" en inglés. [25]
En irlandés , se utiliza el caso camel cuando se añade un prefijo flexivo a un nombre propio, por ejemplo i nGaillimh ("en Galway "), de Gaillimh ("Galway"); an tAlbanach ("la persona escocesa"), de Albanach ("persona escocesa"); y go hÉirinn ("a Irlanda"), de Éire ("Irlanda"). En la ortografía gaélica escocesa reciente , se ha insertado un guion: an t-Albannach .
Esta convención también se utiliza en varias lenguas bantúes escritas (por ejemplo, isiZulu , " lengua zulú ") y en varias lenguas indígenas de México (por ejemplo, náhuatl , totonaco , mixe-zoque y algunas lenguas otomangues ).
En holandés , cuando se escribe con mayúscula el dígrafo ij , se escriben con mayúscula tanto la letra I como la letra J , por ejemplo en el nombre del país IJsland ("Islandia").
En el pinyin chino , a veces se utiliza la mayúscula en mayúsculas para los nombres de lugares, de modo que los lectores puedan distinguir más fácilmente las diferentes partes del nombre. Por ejemplo, lugares como Pekín (北京), Qinhuangdao (秦皇岛) y Daxing'anling (大兴安岭) se pueden escribir como BeiJing , QinHuangDao y DaXingAnLing respectivamente , con el número de letras mayúsculas igual al número de caracteres chinos . Escribir los compuestos de palabras solo con la letra inicial de cada carácter también es aceptable en algunos casos, por lo que Pekín se puede escribir como BJ , Qinghuangdao como QHD y Daxing'anling como DXAL.
En inglés, las mayúsculas mediales normalmente solo se encuentran en los nombres escoceses o irlandeses "Mac-" o "Mc-", donde, por ejemplo, MacDonald, McDonald y Macdonald son variantes ortográficas comunes del mismo nombre, y en los nombres anglonormandos "Fitz-", donde, por ejemplo, se encuentran tanto FitzGerald como Fitzgerald .
En su guía de estilo en inglés The King's English , publicada por primera vez en 1906, HW y FG Fowler sugirieron que se podían usar mayúsculas intermedias en palabras compuestas triples en las que los guiones causarían ambigüedad; los ejemplos que dan son KingMark-like (en contraposición a King Mark-like ) y Anglo-SouthAmerican (en contraposición a Anglo-South American ). Sin embargo, describieron el sistema como "demasiado irremediablemente contrario a su uso en la actualidad". [26]
En la transliteración académica de idiomas escritos en otras escrituras, las mayúsculas medias se utilizan en situaciones similares. Por ejemplo, en hebreo transliterado , haIvri significa "la persona hebrea" o "el judío" y b'Yerushalayim significa "en Jerusalén". En los nombres propios tibetanos como rLobsang , la "r" representa un glifo de prefijo en la escritura original que funciona como marcador de tono en lugar de una letra normal. Otro ejemplo es ts I urku , una transcripción latina del término checheno para la piedra de remate de las características torres defensivas medievales de Chechenia e Ingushetia ; la letra " I " ( palochka ) no es realmente mayúscula, denotando un fonema distinto del transcrito como "i".
Las mayúsculas mediales se utilizan tradicionalmente en abreviaturas para reflejar la capitalización que tendrían las palabras cuando se escribieran completas, por ejemplo, en los títulos académicos PhD o BSc . Un ejemplo más reciente es NaNoWriMo , una contracción de National Novel Writing Month y la designación tanto del evento anual como de la organización sin fines de lucro que lo organiza. En alemán, los nombres de los estatutos se abrevian utilizando mayúsculas incrustadas, por ejemplo, StGB para Strafgesetzbuch (Código Penal), PatG para Patentgesetz (Ley de Patentes), BVerfG para Bundesverfassungsgericht ( Tribunal Constitucional Federal ), o el muy común GmbH, para Gesellschaft mit beschränkter Haftung ( sociedad de responsabilidad limitada ). En este contexto, incluso puede haber tres o más mayúsculas en mayúsculas de camello, por ejemplo, en TzBfG para Teilzeit- und Befristungsgesetz (Ley de ocupaciones a tiempo parcial y de duración limitada). En francés, las siglas en mayúsculas y minúsculas, como OuLiPo (1960), se utilizaron durante un tiempo como alternativas a las iniciales.
El sistema Camel case se utiliza a menudo para transliterar siglas en alfabetos donde pueden necesitarse dos letras para representar un solo carácter del alfabeto original, por ejemplo, DShK del cirílico ДШК.
El primer uso sistemático y generalizado de las mayúsculas medias con fines técnicos fue la notación para fórmulas químicas inventada por el químico sueco Jacob Berzelius en 1813. Para reemplazar la multitud de convenciones de nombres y símbolos utilizados por los químicos hasta ese momento, propuso indicar cada elemento químico mediante un símbolo de una o dos letras, siendo la primera mayúscula. La capitalización permitió que fórmulas como " NaCl " se escribieran sin espacios y aún así se analizaran sin ambigüedad. [27] [28]
El sistema de Berzelius sigue utilizándose, ampliado con símbolos de tres letras como " Uue " para elementos no confirmados o desconocidos y abreviaturas para algunos sustituyentes comunes (especialmente en el campo de la química orgánica, por ejemplo " Et " para "etilo-"). Esto se ha ampliado aún más para describir las secuencias de aminoácidos de las proteínas y otros dominios similares.
Desde principios del siglo XX, las mayúsculas medias se han utilizado ocasionalmente para nombres corporativos y marcas comerciales de productos, como
En los años 1970 y 1980, las mayúsculas medias se adoptaron como una convención de nomenclatura estándar o alternativa para los identificadores de varias palabras en varios lenguajes de programación . El origen preciso de la convención en la programación informática aún no se ha establecido. En las actas de una conferencia de 1954 [32], ocasionalmente se hacía referencia informal al sistema Speedcoding de IBM como "SpeedCo". El artículo de Christopher Strachey sobre GPM (1965), [33] muestra un programa que incluye algunos identificadores de mayúsculas medias, incluidos " " y " " (lo más probable es que esto haya sido la influencia del lenguaje CPL , del cual Strachey fue uno de los diseñadores).NextChWriteSymbol
Los identificadores descriptivos de varias palabras con espacios incrustados, como end of fileo, char tableno se pueden utilizar en la mayoría de los lenguajes de programación porque los espacios entre las palabras se analizarían como delimitadores entre tokens . La alternativa de ejecutar las palabras juntas como en endoffileo chartablees difícil de entender y posiblemente engañosa; por ejemplo, chartablees una palabra en inglés (que se puede representar gráficamente), mientras que charTablesignifica una tabla de chars.
Algunos de los primeros lenguajes de programación, en particular Lisp (1958) y COBOL (1959), abordaron este problema permitiendo el uso de un guión ("-") entre palabras de identificadores compuestos, como en "END-OF-FILE": Lisp porque funcionaba bien con la notación de prefijo (un analizador de Lisp no trataría un guión en medio de un símbolo como un operador de sustracción) y COBOL porque sus operadores eran palabras individuales en inglés. Esta convención sigue utilizándose en estos lenguajes y también es común en los nombres de programas ingresados en una línea de comandos , como en Unix.
Sin embargo, esta solución no era adecuada para lenguajes orientados a las matemáticas como FORTRAN (1955) y ALGOL (1958), que utilizaban el guión como operador de sustracción de infijos. FORTRAN ignoraba los espacios en blanco por completo, por lo que los programadores podían utilizar espacios incrustados en los nombres de las variables. Sin embargo, esta característica no era muy útil ya que las primeras versiones del lenguaje restringían los identificadores a no más de seis caracteres.
Para agravar el problema, los conjuntos de caracteres comunes de las tarjetas perforadas de la época solo estaban en mayúsculas y carecían de otros caracteres especiales. Recién a fines de la década de 1960, la adopción generalizada del conjunto de caracteres ASCII hizo que tanto las minúsculas como el carácter de guión bajo_ estuvieran disponibles universalmente. Algunos lenguajes, en particular C , adoptaron rápidamente guiones bajos como separadores de palabras e identificadores como los que end_of_fileaún prevalecen en los programas y bibliotecas de C (así como en lenguajes posteriores influenciados por C, como Perl y Python ). Sin embargo, algunos lenguajes y programadores optaron por evitar los guiones bajos (entre otras razones para evitar confundirlos con espacios en blanco ) y adoptaron en su lugar el formato camel case.
Charles Simonyi , que trabajó en Xerox PARC en la década de 1970 y más tarde supervisó la creación de la suite de aplicaciones Office de Microsoft, inventó y enseñó el uso de la notación húngara , una versión de la cual utiliza la(s) letra(s) minúscula(s) al comienzo de un nombre de variable (en mayúscula) para indicar su tipo. Un relato [ cita requerida ] afirma que el estilo camel case se hizo popular por primera vez en Xerox PARC alrededor de 1978, con el lenguaje de programación Mesa desarrollado para la computadora Xerox Alto . Esta máquina carecía de una tecla de subrayado (cuyo lugar estaba ocupado por una flecha hacia la izquierda "←"), y los caracteres de guion y espacio no estaban permitidos en los identificadores, dejando a camel case como el único esquema viable para nombres legibles de varias palabras. El Manual del lenguaje Mesa de PARC (1979) incluía un estándar de codificación con reglas específicas para camel case mayúsculas y minúsculas que era estrictamente seguido por las bibliotecas Mesa y el sistema operativo Alto. Niklaus Wirth , el inventor de Pascal , comenzó a apreciar CamelCase durante un año sabático en PARC y lo utilizó en Modula , su siguiente lenguaje de programación. [34]
El lenguaje Smalltalk , que se desarrolló originalmente en Alto, también utiliza el sistema CamelCase en lugar de guiones bajos. Este lenguaje se volvió bastante popular a principios de los años 80 y, por lo tanto, también puede haber sido fundamental en la difusión del estilo fuera de PARC.
En Wolfram Language, en el sistema algebraico computacional Mathematica se utiliza la escritura en mayúsculas (o "Pascal case") para los identificadores predefinidos. Los identificadores definidos por el usuario deben comenzar con una letra minúscula. Esto evita el conflicto entre los identificadores predefinidos y los definidos por el usuario, tanto en la actualidad como en todas las versiones futuras.
Se recomienda que los nombres de las variables de C# sigan la convención de mayúsculas y minúsculas. [35]
Cualquiera que sea su origen en el campo de la informática, la convención se utilizó en los nombres de las empresas de informática y sus marcas comerciales desde finales de la década de 1970, una tendencia que continúa hasta el día de hoy:
En los años 1980 y 1990, después de que la llegada de la computadora personal expusiera la cultura hacker al mundo, el término camel case se puso de moda también para los nombres comerciales de empresas en campos no informáticos. En 1990, su uso generalizado ya estaba bien establecido:
Durante la burbuja punto-com de finales de los años 1990, los prefijos minúsculos "e" (de " electrónico ") e "i" (de "Internet", [36] "información", " inteligente ", etc.) se volvieron bastante comunes, dando lugar a nombres como iMac de Apple y la plataforma de software eBox .
En 1998, Dave Yost sugirió que los químicos utilizaran mayúsculas medias para facilitar la legibilidad de nombres químicos largos, por ejemplo, escribir AmidoPhosphoRibosylTransferase en lugar de amidophosphoribosyltransferase . [37] Este uso no fue ampliamente adoptado.
En ocasiones, se utiliza la mayúscula Camel para los nombres abreviados de ciertos barrios, por ejemplo, los barrios de la ciudad de Nueva York SoHo ( al sur de Houston Street ) y TriBeCa ( TriangleBelowCa nal Street) y SoMa ( al sur de Market ) de San Francisco. Estos usos se erosionan rápidamente, por lo que ahora los barrios se suelen representar como Soho , Tribeca y Soma .
La capitalización interna también se ha utilizado para otros códigos técnicos como HeLa (1983).
El uso de mayúsculas intermedias para los identificadores compuestos es recomendado por las pautas de estilo de codificación de muchas organizaciones o proyectos de software. Para algunos lenguajes (como Mesa , Pascal , Modula , Java y .NET de Microsoft ), esta práctica es recomendada por los desarrolladores del lenguaje o por manuales autorizados y, por lo tanto, se ha convertido en parte de la "cultura" del lenguaje.
Las pautas de estilo a menudo distinguen entre mayúsculas y minúsculas, y generalmente especifican qué variedad se debe utilizar para tipos específicos de entidades: variables , campos de registro , métodos , procedimientos , funciones , subrutinas , tipos , etc. Estas reglas a veces están respaldadas por herramientas de análisis estático que verifican el código fuente para verificar su cumplimiento.
La notación húngara original para programación, por ejemplo, especifica que una abreviatura en minúscula para el "tipo de uso" (no el tipo de datos) debe preceder a todos los nombres de variables, y el resto del nombre en mayúsculas; como tal, es una forma de minúsculas.
Los identificadores de programación a menudo necesitan contener acrónimos y siglas que ya están en mayúsculas, como "archivo HTML antiguo". Por analogía con las reglas de mayúsculas y minúsculas, la representación natural con mayúsculas y minúsculas tendría la abreviatura en mayúsculas, es decir, "archivoHTMLantiguo". Sin embargo, este enfoque es problemático cuando dos acrónimos aparecen juntos (por ejemplo, "parse DBM XML" se convertiría en "parseDBMXML") o cuando el estándar exige mayúsculas y minúsculas pero el nombre comienza con una abreviatura (por ejemplo, "servidor SQL" se convertiría en "sQLServer"). Por esta razón, algunos programadores prefieren tratar las abreviaturas como si fueran palabras y escribir "archivoHTMLantiguo", "parseDbmXml" o "sqlServer". [38] Sin embargo, esto puede hacer que sea más difícil reconocer que una palabra determinada está destinada a ser un acrónimo. [39]
Las dificultades surgen cuando los identificadores tienen un significado diferente según si se trata de mayúsculas o minúsculas, como puede ocurrir con las funciones matemáticas o las marcas comerciales. En esta situación, cambiar el uso de mayúsculas o minúsculas de un identificador puede no ser una opción y debe elegirse un nombre alternativo.
El uso de Camel case se utiliza en algunos lenguajes de marcado wiki para términos que deberían vincularse automáticamente a otras páginas wiki . Esta convención se utilizó originalmente en el software wiki original de Ward Cunningham , WikiWikiWeb , [40] y se puede activar en la mayoría de las otras wikis. Algunos motores wiki como TiddlyWiki , Trac y PmWiki lo utilizan en la configuración predeterminada, pero normalmente también proporcionan un mecanismo de configuración o un complemento para desactivarlo. Wikipedia también utilizaba anteriormente el uso de Camel case para los enlaces, pero cambió al marcado de enlaces explícito mediante corchetes [41] y muchos otros sitios wiki han hecho lo mismo. MediaWiki , por ejemplo, no admite Camel case para los enlaces. Algunas wikis que no utilizan Camel case para los enlaces pueden seguir utilizando Camel case como convención de nomenclatura, como AboutUs .
El registro NIEM requiere que los elementos de datos XML utilicen mayúsculas y los atributos XML utilicen minúsculas.
La mayoría de las interfaces de línea de comandos y lenguajes de programación más populares no pueden manejar fácilmente nombres de archivos que contienen espacios incrustados (por lo general, es necesario poner el nombre entre comillas). Por lo tanto, los usuarios de esos sistemas a menudo recurren al uso de mayúsculas y minúsculas (o guiones bajos, guiones y otros caracteres "seguros") para nombres de archivos compuestos como MyJobResume.pdf .
Los servicios de microblogging y redes sociales que limitan el número de caracteres en un mensaje son salidas potenciales para las mayúsculas medias. El uso de CamelCase entre palabras reduce el número de espacios, y por lo tanto el número de caracteres, en un mensaje dado, lo que permite que quepa más contenido en el espacio limitado. Los hashtags , especialmente los largos, a menudo utilizan CamelCase para mantener la legibilidad (por ejemplo, #CollegeStudentProblems es más fácil de leer que #collegestudentproblems); [42] esta práctica mejora la accesibilidad ya que los lectores de pantalla reconocen CamelCase al analizar hashtags compuestos. [43]
En las URL de los sitios web, los espacios se codifican con porcentajes como "%20", lo que hace que la dirección sea más larga y menos legible para las personas . Al omitir los espacios, CamelCase no tiene este problema.
Se ha criticado el uso de Camel case por afectar negativamente la legibilidad debido a la eliminación de espacios y mayúsculas en cada palabra. [44]
Un estudio de 2009 de 135 sujetos que comparaba el caso de serpiente (identificadores subrayados) con el caso de camello encontró que los identificadores del caso de camello fueron reconocidos con mayor precisión entre todos los sujetos. Los sujetos reconocieron los identificadores del caso de serpiente más rápidamente que los identificadores del caso de camello. El entrenamiento en el caso de camello aceleró el reconocimiento del caso de camello y ralentizó el reconocimiento del caso de serpiente, aunque este efecto involucró coeficientes con altos valores p . El estudio también realizó una encuesta subjetiva y encontró que los no programadores preferían los guiones bajos o no tenían preferencia, y el 38% de los programadores entrenados en el caso de camello manifestaron una preferencia por los guiones bajos. Sin embargo, estas preferencias no tenían correlación estadística con la precisión o la velocidad al controlar otras variables. [45]
Un estudio de seguimiento de 2010 utilizó un diseño de estudio similar con 15 sujetos que consistían en programadores expertos entrenados principalmente en el caso de la serpiente. Utilizó un estímulo estático en lugar de animado y encontró una precisión perfecta en ambos estilos, excepto por una respuesta incorrecta en el caso del camello. Los sujetos reconocieron los identificadores en el caso de la serpiente más rápidamente que en el caso del camello. El estudio utilizó un equipo de seguimiento ocular y encontró que la diferencia en la velocidad de sus sujetos se debía principalmente al hecho de que la duración promedio de las fijaciones para el caso del camello era significativamente mayor que la del caso de la serpiente para los identificadores de 3 partes. La encuesta registró una mezcla de estilos de identificadores preferidos, pero nuevamente no hubo correlación del estilo preferido con la precisión o la velocidad. [46]
{{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace )En términos de identificadores con CamelCase, esto tiene un mayor impacto en los identificadores que incluyen palabras cortas y especialmente acrónimos. Por ejemplo, considere el ID del acrónimo que se encuentra en el identificador kIOuterIIDPath. Debido a la sucesión de letras mayúsculas, la tarea de leer kIOuterIIDPath, en particular la identificación del ID de la palabra, es más difícil.
El experimento se basa en trabajos anteriores de otros que estudian cómo los lectores de lenguaje natural realizan tales tareas. Los resultados indican que el uso de CamelCase conduce a una mayor precisión entre todos los sujetos independientemente del entrenamiento, y aquellos entrenados en CamelCase pueden reconocer identificadores en el estilo CamelCase más rápido que los identificadores en el estilo Under_score.
Se presenta un estudio empírico para determinar si las convenciones de denominación de identificadores (es decir, camelCase y under_score) afectan la comprensión del código. Se utiliza un rastreador ocular para capturar datos cuantitativos de sujetos humanos durante un experimento. La intención de este estudio es replicar un estudio previo publicado en ICPC 2009 (Binkley et al.) que utilizó un método de prueba de respuesta cronometrada para adquirir datos. El uso de equipos de seguimiento ocular proporciona información adicional y supera algunas limitaciones de las técnicas tradicionales de recopilación de datos. Se discuten las similitudes y diferencias entre los dos estudios. Una diferencia principal es que los sujetos fueron entrenados principalmente en el estilo de guión bajo y todos eran programadores. Si bien los resultados no indican ninguna diferencia en la precisión entre los dos estilos, los sujetos reconocen los identificadores en el estilo de guión bajo más rápidamente.
