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();

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.

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 Taxes → usTaxes
• Player ID → playerId

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")

• Consulte "EDXML" en este esquema XML
• Consulte "SFAS158" en este esquema XBRL

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

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 .

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.

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.

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 = [
  // ...
];

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.

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.

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

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

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

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.