Acrónimos en CamelCase [cerrado]

243

Tengo una duda sobre CamelCase. Supongamos que tienes este acrónimo:Unesco = United Nations Educational, Scientific and Cultural Organization.

Deberías escribir: unitedNationsEducationalScientificAndCulturalOrganization

Pero, ¿qué pasa si necesitas escribir el acrónimo? Algo como:

getUnescoProperties();

¿Es correcto escribirlo de esta manera? getUnescoProperties() OR getUNESCOProperties();

gal007
fuente
2
¿No debería ser esto en programadores.SE?
Pacerier
55
La conversión de IMO a snake_case revela la mejor solución. Qué le gusta get_unesco_propertieso get_u_n_e_s_c_o_properties?
jchook 05 de
Publicación relacionada: ¿la variable debe llamarse Id o ID?
RBT
Pregunta relacionada: stackoverflow.com/questions/4504508/camel-casing-acrimony
Anton Tarasenko

Respuestas:

195

Algunas pautas sobre las que Microsoft ha escrito camelCaseson:

Cuando use acrónimos, use el caso Pascal o el caso camel para acrónimos de más de dos caracteres de largo. Por ejemplo, use HtmlButtono htmlButton. Sin embargo, debe poner en mayúscula las siglas que constan de solo dos caracteres, como en System.IOlugar de System.Io.

No use abreviaturas en identificadores o nombres de parámetros. Si debe usar abreviaturas, use mayúsculas y minúsculas para abreviaturas que consisten en más de dos caracteres, incluso si esto contradice la abreviatura estándar de la palabra.

Resumiendo:

  • Cuando use una abreviatura o acrónimo de dos caracteres de largo, póngalos todos en mayúscula;

  • Cuando el acrónimo es más largo que dos caracteres, use una capital para el primer personaje.

Entonces, en su caso específico, getUnescoProperties()es correcto.

SOFTWARE Apollo
fuente
11
Supongo que debería comenzar a usar en su IDlugar Id(que uso / veo en todas partes)
jasonscript
30
Técnicamente "ID" no es un acrónimo (es una abreviatura de "identificador" o "identificación"), pero realmente no sé cómo / si esta guía ayuda con eso. : - \
bryant
64
No creo que este sea un buen estándar. Distinguir acrónimos normales, acrónimos de dos letras y palabras normales parece demasiado complicado y contrario a la idea de tener una convención de nomenclatura coherente.
Sam
40
Además, ser declarado por Microsoft no hace que algo sea "correcto".
Sam
48
Es bueno saber que siguen sus propias pautas: XMLHttpRequest()originalmente vinieron de Microsoft.
Makyen
315

Hay críticas legítimas de los consejos de Microsoft de la respuesta aceptada.

  • Tratamiento inconsistente de siglas / initialisms dependiendo del número de caracteres:
    • playerIDvs playerIdvs playerIdentifier.
  • La pregunta de si los acrónimos de dos letras aún deben escribirse en mayúscula si aparecen al comienzo del identificador:
    • USTaxes vs usTaxes
  • Dificultad para distinguir múltiples siglas:
    • es decir, USIDvs usId(o parseDBMXMLen el ejemplo de Wikipedia).

Entonces publicaré esta respuesta como una alternativa a la respuesta aceptada. Todos los acrónimos deben ser tratados consistentemente; Las siglas deben tratarse como cualquier otra palabra. Citando Wikipedia :

... algunos programadores prefieren tratar las abreviaturas como si fueran minúsculas ...

Entonces, re: pregunta de OP, estoy de acuerdo con la respuesta aceptada; esto es correcto:getUnescoProperties()

Pero creo que llegaría a una conclusión diferente en estos ejemplos:

  • US TaxesusTaxes
  • Player IDplayerId

Por lo tanto, vote por esta respuesta si cree que los acrónimos de dos letras deben tratarse como otros acrónimos.

Camel Case es una convención, no una especificación. Así que supongo que las reglas de opinión popular.

( EDITAR: Eliminar esta sugerencia de que los votos deberían decidir este tema; como dice @Brian David; Stack Overflow no es un "concurso de popularidad", y esta pregunta se cerró como "basada en la opinión")

Aunque muchos prefieren tratar los acrónimos como cualquier otra palabra, la práctica más común puede ser poner acrónimos en mayúsculas (aunque conduzca a "abominaciones")

Otros recursos:

  • Tenga en cuenta que algunas personas distinguen entre abreviaturas y siglas
  • Tenga en cuenta que las pautas de Microsoft distinguen entre acrónimos de dos caracteres y "acrónimos de más de dos caracteres"
  • Tenga en cuenta que algunas personas recomiendan evitar las abreviaturas / acrónimos por completo
  • Tenga en cuenta que algunas personas recomiendan evitar CamelCase / PascalCase por completo
  • Tenga en cuenta que algunas personas distinguen entre "consistencia" como "reglas que parecen internamente inconsistentes" (es decir, tratar acrónimos de dos caracteres diferentes a los acrónimos de tres caracteres); algunas personas definen "consistencia" como "aplicar la misma regla de manera consistente" (incluso si la regla es internamente inconsistente)
  • Pautas de diseño del marco
  • Pautas de Microsoft
The Red Pea
fuente
26
1) No hay inconsistencia. "Id" es una abreviatura , no un acrónimo. 2) Depende del contexto del identificador, es decir, clase, interfaz, atributo, tipo de enumeración, campo estático, parámetro, método, propiedad o evento. Si la guía para el identificador está usando PascalCase, entonces sería USTaxesy PlayerId; camelCase: usTaxesy playerId. 3) Sería USIden PascalCase, usIden camelCase y parseDbmXmlen camelCase.
Frederik Krautwald
66
Tienes razón, es una abreviatura. Mi punto es que debería ser UsTaxes, UsId. La "abreviatura o acrónimo" de dos letras no debe tratarse de manera diferente que las tres letras u otras "palabras normales". Otro consejo, de la respuesta de @ Eonil, es evitar los acortadores por completo. unitedStatesTaxes o playerIdentifier.
The Red Pea
3
Jaja. Dudo que surja la confusión, mucho, pero las pautas son, bueno, pautas para evitar una posible confusión. Un ejemplo de acrónimo ideado (malo) en un contexto científico: InIN(item)vs InIn(item)(pista: IN es pulgadas (s)). O, IDById(id)vs IdById(id), ciencia del contexto (pista: ID significa enfermedad infecciosa). "Dos caracteres de largo": ¿en qué contexto?
Frederik Krautwald
2
En el enlace de Microsoft "... use el caso Pascal o el caso camel para acrónimos de más de dos caracteres de largo ... Sin embargo, debe poner en mayúscula los acrónimos que consisten en solo dos caracteres ..." Esa es la parte que llamaría "inconsistente ". Una mejor caracterización es la "excepción". Y al menos has racionalizado por qué las siglas de dos letras podrían ser más confusas. Pero supongo que esos programas con "CanCan" no tienen suerte; ambiguo ya sea el movimiento de baile o la red de área comunitaria del Cercle de l'Aviron de Nantes :)
The Red Pea
18
El autor de Capital Offense: How to Hand Abbreviations in CamelCase invoca correctamente el término "abominación" cuando escribe: "Si bien [el uso de siglas en mayúsculas] funciona en casos simples, genera abominaciones cuando una abreviatura sigue a otra: HTTPURLConnection, XMLIDREF"
kghastie
21

Primero, tengo que aclarar que no soy un hablante nativo de inglés , por lo que mi afirmación sobre la gramática inglesa puede simplemente estar equivocada. Si descubre tales errores, hágamelo saber y le estaré muy agradecido.


La mejor práctica para el acrónimo sería evitar los acrónimos tanto como sea posible. De todos modos, este no es el caso porque el acrónimo UNESCOes más familiar que el nombre completo UnitedNationsEducationalScientificAndCulturalOrganization.

Entonces, creo que UNESCOtiene más sentido que Unescoporque simplemente está más cerca de la forma de la vida real y es más familiar. Tuve algunos problemas para entender qué Unescosignifica realmente la palabra .

Como otro ejemplo, piense en Arc. Esto suena como una curva alrededor de un círculo, pero en Rust, esto significa Atomically Reference Counted. Si se ha escrito así ARC, al menos los lectores reconocerían que la palabra es un acrónimo de algo más que una especie de curva.

Los programas modernos están escritos principalmente para lectores humanos. Entonces, esas reglas de nomenclatura deben establecerse para la legibilidad humana en lugar del procesamiento o análisis de la máquina.

En esta perspectiva, se pierde un poco de lectura mediante el uso de Unescomás UNESCOtiempo que obtienen nada.

Y para cualquier otro caso, creo que solo seguir las reglas (o convenciones) acrónimas en inglés es suficiente para la mayoría de los casos para una mejor legibilidad .

Eonil
fuente
44
Los ejemplos anteriores son un poco engañosos. "El mejor enfoque que he visto fue el de Apple ... Eso significa tratar los acrónimos como un nombre propio ... Así que la UNESCO tiene más sentido" - Así no es como se escriben los nombres propios.
Mikko Rantanen
@MikkoRantanen Actualicé mi respuesta.
Eonil
77
Wow, apenas puedo encontrar una oración en esa respuesta con la que estaría de acuerdo :-)
Josef Sábl
Depende completamente del contexto del código en el que esté trabajando si las abreviaturas / siglas tienen más o menos sentido. Por ejemplo, trabajo en finanzas, y hay muchos términos únicos que son uniformes en toda la industria y, de hecho, en todo el mundo. Estaría perdiendo el tiempo y creando verbosidad innecesaria al no usar siglas que todos los que trabajarán en esa compañía se saben de memoria. Por ejemplo, PV para el valor actual, FV para el valor futuro, promedio para el promedio, exp para el exponente, etc.
Ediger
@ pm100 ¿No es eso lo que dije? La UNESCO no es cómo se escriben los nombres propios.
Mikko Rantanen
17

Para convertir a CamelCase, también existe el algoritmo de caso Camel (casi) determinista de Google :

Comenzando con la forma en prosa del nombre:

  1. Convierta la frase a ASCII simple y elimine los apóstrofes. Por ejemplo, el "algoritmo de Müller" podría convertirse en el "algoritmo de Muellers".
  2. Divida este resultado en palabras, dividiendo en espacios y cualquier puntuación restante (generalmente guiones).
    1. Recomendado: si alguna palabra ya tiene una apariencia de caso de camello convencional en uso común, divídala en sus partes constituyentes (por ejemplo, "AdWords" se convierte en "palabras publicitarias"). Tenga en cuenta que una palabra como "iOS" no está realmente en el caso de camello per se; desafía cualquier convención, por lo que esta recomendación no se aplica.
  3. Ahora todo en minúscula (incluidos los acrónimos), luego en mayúscula solo el primer carácter de:
    1. ... cada palabra, para producir mayúsculas de camello, o
    2. ... cada palabra, excepto la primera, para producir un caso de camello más bajo
  4. Finalmente, une todas las palabras en un solo identificador.

Tenga en cuenta que la carcasa de las palabras originales se ignora casi por completo.

En los siguientes ejemplos, la "solicitud XML HTTP" se transforma correctamente a XmlHttpRequest, XMLHTTPRequest es incorrecta.

serv-inc
fuente
17

getUnescoProperties() debería ser la mejor solución ...

Cuando sea posible, solo siga el puro camelCase, cuando tenga acrónimos, simplemente déjelos en mayúscula cuando sea posible, de lo contrario, vaya camelCase.

En general, en OO, las variables de programación deben comenzar con letras minúsculas ( lowerCamelCase) y la clase debe comenzar con letras mayúsculas ( UpperCamelCase).

En caso de duda, simplemente ir puro camelCase;)

parseXMLestá bien, parseXmles tambiéncamelCase

XMLHTTPRequestdebe ser XmlHttpRequesto xmlHttpRequestno el camino a seguir con acrónimos de mayúsculas posteriores, definitivamente no está claro para todos los casos de prueba.

por ejemplo, cómo se lee esta palabra HTTPSSLRequest, HTTP + SSLo HTTPS + SL(eso no significa nada más que ...), en ese caso, siga la convención de casos de camellos y busque httpSslRequesto httpsSlRequest, tal vez ya no sea agradable, pero definitivamente es más claro.

luk_z
fuente
2
Me gusta su HTTPSSLejemplo, aunque SL no significa nada, ¿qué tal algo como HTTPSSHTunnel? ¿Es HTTPS + SH (shell) o HTTP + SSH? La convención de Google es definitivamente menos ambigua.
L. Holanda
10

Hay una guía de estilo JavaScript de airbnb en github con muchas estrellas (~ 57.5k en este momento) y guías sobre acrónimos que dicen:

Los acrónimos y los inicialismos siempre deben estar en mayúsculas o en minúsculas.

¿Por qué? Los nombres son para facilitar la lectura, no para apaciguar un algoritmo informático.

// bad
import SmsContainer from './containers/SmsContainer';

// bad
const HttpRequests = [
  // ...
];

// good
import SMSContainer from './containers/SMSContainer';

// good
const HTTPRequests = [
  // ...
];

// also good
const httpRequests = [
  // ...
];

// best
import TextMessageContainer from './containers/TextMessageContainer';

// best
const requests = [
  // ...
];
valex
fuente
77
" ¿Por qué? Los nombres son para facilitar la lectura, no para apaciguar un algoritmo informático ", entonces, XMLHTTPRequestes mucho mejor legible que XmlHttpRequest, ¿verdad?
L. Holanda
2
No tiene sentido por qué httpRequestsse considera bueno, pero HttpRequestses malo. siguiendo este principio, entonces, para XML HTTP Request debería ser xmlhttpRequest???
L. Holanda
1
A menudo cito la guía de estilo de AirBnb, pero en este caso no estoy de acuerdo. Particularmente, no estoy de acuerdo con su afirmación: "Las siglas y los iniciales deben estar siempre en mayúsculas o minúsculas". xmlHttpRequestes más legible que XMLHTTPRequesten mi opinión.
Ronan
3

Actualmente estoy usando las siguientes reglas:

  1. Caso de pena capital para los acrónimos: XMLHTTPRequest, xmlHTTPRequest, requestIPAddress.

  2. Caso del camello por abreviaturas: ID[entifier], Exe[cutable], App[lication].

ID Es una excepción, lo siento pero es cierto.

Cuando veo una letra mayúscula, asumo un acrónimo, es decir, una palabra separada para cada letra. Las abreviaturas no tienen palabras separadas para cada letra, por lo que uso el caso de camello.

XMLHTTPRequest es ambiguo, pero es un caso raro y no es tan ambiguo, así que está bien, las reglas y la lógica son más importantes que la belleza.

usuario2992258
fuente
1

La guía de estilo JavaScript Airbnb habla un poco sobre esto . Básicamente:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

Como normalmente leo una letra mayúscula principal como clase, tiendo a evitar eso. Al final del día, todo es preferencia.

Bryantee
fuente
1

Además de lo que ha dicho @valex, quiero recapitular un par de cosas con las respuestas dadas para esta pregunta.

Creo que la respuesta general es: depende del lenguaje de programación que esté utilizando.

C Sharp

Microsoft ha escrito algunas pautas donde parece que esa HtmlButtones la forma correcta de nombrar una clase para estos casos.

Javascript

Javascript tiene algunas variables globales con siglas y las usa todas en mayúscula (pero curiosamente, no siempre de manera consistente) aquí hay algunos ejemplos:

encodeURIComponent XMLHttpRequest toJSON toISOString

lante
fuente
Bueno, es Netscape viejo, incluso tiene algunos sin camelCase como onerror.
Eddie
1

descargo de responsabilidad: el inglés no es mi tono materno. Pero he pensado en este problema durante mucho tiempo, especialmente cuando uso el nodo (estilo camelcase) para manejar la base de datos, ya que el nombre de los campos de la tabla debe ser una serpiente, este es mi pensamiento:

Hay 2 tipos de 'acrónimos' para un programador:

  • en lenguaje natural, UNESCO
  • en lenguaje de programación de computadoras, por ejemplo tmc and textMessageContainer, que generalmente aparece como una variable local.

En el mundo de la programación, todas las siglas en lenguaje natural deben tratarse como palabras , las razones son:

  1. cuando programamos, deberíamos nombrar una variable ya sea en estilo de acrónimo o sin estilo de acrónimo. Entonces, si nombramos una función getUNESCOProperties, significa que UNESCO es un acrónimo (de lo contrario, no deberían ser todas letras mayúsculas), pero evidentemente, gety propertiesno son acrónimos. entonces, deberíamos nombrar esta función como gunescop o getUnitedNationsEducationalScientificAndCulturalOrganizationProperties , ambas son inaceptables.

  2. el lenguaje natural está evolucionando continuamente, y las siglas de hoy se convertirán en palabras mañana , pero los programas deberían ser independientes de esta tendencia y permanecer para siempre.

por cierto, en la respuesta más votada, IO es el acrónimo en el significado del lenguaje de computadora (significa InputOutput), pero no me gusta el nombre, ya que creo que el acrónimo (en lenguaje de computadora) solo debe usarse para nombrar una variable local pero una clase / función de nivel superior, por lo que se debe usar InputOutput en lugar de IO

xiechao06
fuente
"lengua", no "tono"
Dan Dascalescu
0

La UNESCO es un caso especial, ya que generalmente (en inglés) se lee como una palabra y no como un acrónimo, como UEFA, RADA, BAFTA y, a diferencia de BBC, HTML, SSL

usuario1833431
fuente
1
Esta es la distinción entre "acrónimos" y meras "abreviaturas"; Esta distinción parece ser relevante para toda la discusión, pero se ha eludido casi por completo en las respuestas presentadas.
Simon
BBC, HTML, SSL y otras siglas donde suena cada letra se llaman más exactamente initialisms. Palabras como la UNESCO que se pronuncian como una palabra son acrónimos verdaderos.
Lrdwhyt
-2

También hay otra convención camelcase que trata de favorecer la legibilidad de los acrónimos utilizando mayúsculas ( HTML) o minúsculas ( html), pero evitando ambas ( Html).

Entonces en tu caso podrías escribir getUNESCOProperties. También puede escribir unescoPropertiespara una variable o UNESCOPropertiespara una clase (la convención para las clases es comenzar con mayúsculas).

Esta regla se vuelve complicada si desea juntar dos siglas, por ejemplo, para una clase llamada XML HTTP Request. Sería empezar con mayúscula, pero ya XMLHTTPRequestno sería fácil de leer (? Es que XMLH TTP Solicitud), y XMLhttpRequestse rompería la convención CamelCase (? Es que XM LHTTP Solicitud), la mejor opción sería la de la casuística: XMLHttpRequest, que es en realidad lo que usó el W3C . Sin embargo, se desaconseja el uso de este tipo de nombres. Para este ejemplo, HTTPRequestsería un mejor nombre.

Dado que la palabra oficial en inglés para identificación / identidad parece ser ID, aunque no es un acrónimo, puede aplicar las mismas reglas allí.

Esta convención parece ser bastante popular, pero es solo una convención y no hay bien o mal. Solo trate de cumplir con una convención y asegúrese de que sus nombres sean legibles.

Jesús Carrera
fuente
3
No creo todo este hilo :-) ¿Entonces sería XMLToHtmlConverter pero HTMLToXmlConverter? Wow ...
Josef Sábl
1
@ JosefSábl, sí, sería así. Con respecto a su voto negativo, no estoy diciendo que me guste esta convención, pero definitivamente existe.
Jesús Carrera
1
Leí la pregunta como "¿Qué es una buena convención de escribir Accrónimos en camello" y no "¿Puedes enumerar todas las convenciones que existen". Y como considero que su convención mencionada es muy mala,
voté a favor
Bueno, la pregunta es "¿Es correcto escribirlo de esta manera?", Y dado que hay muchas formas "correctas" de escribirlo porque es solo una convención, y esta convención es bastante popular (independientemente de cómo lo consideres), mi la respuesta es muy válida :-)
Jesús Carrera