coding style - sirve - Acrónimos en CamelCase

para que sirve la etiqueta cite en html

Question

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

Debería escribir: unitedNationsEducationalScientificAndCulturalOrganization

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

getUnescoProperties();

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

Answer 1

Actualmente estoy usando las siguientes reglas:

1. Capital mayúscula para acrónimos: XMLHTTPRequest , xmlHTTPRequest , requestIPAddress .

2. Camel case para 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, entonces uso camel case.

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

Answer 2

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és usando.

C Sharp

Microsoft ha escrito algunas pautas donde parece que HtmlButton es la manera correcta de nombrar una clase para este caso.

Javascript

Javascript tiene algunas variables globales con acrónimos y los usa todos en mayúsculas (pero curiosamente, no siempre consistentemente) aquí hay algunos ejemplos:

encodeURIComponent XMLHttpRequest toJSON toISOString

Answer 3

Algunas guidelines Microsoft ha escrito sobre camelCase son:

Cuando use acrónimos, use el estuche Pascal o camel case para acrónimos de más de dos caracteres de longitud. Por ejemplo, use HtmlButton o htmlButton . Sin embargo, debe poner en mayúscula las siglas que constan de solo dos caracteres, como System.IO lugar de System.Io .

No use abreviaturas en identificadores o nombres de parámetros. Si debe usar abreviaturas, use camel case para abreviaturas que constan de 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, colóquelos todos en mayúsculas;

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

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

Answer 4

Existen críticas legítimas al guidelines de la respuesta aceptada.

• Tratamiento inconsistente de acrónimos / iniciales dependiendo del número de caracteres:
  • playerID vs playerId vs playerIdentifier .
• La cuestión 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 acrónimos:
  • es decir, USID vs usId (o parseDBMXML en el ejemplo de Wikipedia).

Entonces publicaré esta respuesta como una alternativa a la respuesta aceptada. Los votos pueden decidir. Todos los acrónimos deben tratarse consistentemente; los acrónimos deben tratarse como cualquier otra palabra. Citando Wikipedia :

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

Entonces, estoy en la 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 US Taxes
• Player ID → playerId

Así que 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 la opinión popular gobierna.

Y al buscar la respuesta "popular" en el código o marcado existente, tal vez la respuesta aceptada lo hizo bien.

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

Answer 5

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

Los acrónimos y las iniciales siempre deben estar en mayúscula o en minúscula.

¿Por qué? Los nombres son para legibilidad, no para apaciguar un algoritmo de la computadora.

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

Answer 6

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

Answer 7

La guía de estilo de JavaScript Airbnb acronyms . Básicamente:

// bad
const HttpRequests = [ req ];
// good
const httpRequests = [ req ];
// also good
const HTTPRequests = [ req ];

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

Answer 8

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

A partir de la forma en prosa del nombre:

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

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

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

Answer 9

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

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

Entonces, creo que la UNESCO tiene más sentido que la Unesco porque simplemente está más cerca de la forma de la vida real, por lo que es más familiar. Tuve algunos problemas para descubrir qué significa realmente la palabra Unesco .

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 como ARC , al menos los lectores reconocerían que la palabra es un acrónimo de algo más que un tipo de curva.

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

Desde esta perspectiva, perdemos cierta legibilidad al utilizar a la Unesco en lugar de la UNESCO sin ganar nada.

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

Answer 10

También hay otra convención de casetes que intenta 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 unescoProperties para una variable, o UNESCOProperties para una clase (la convención para las clases es comenzar con mayúsculas).

Esta regla se vuelve complicada si quiere juntar dos acrónimos, por ejemplo para una clase llamada XML HTTP Request. Empezaría con mayúsculas, pero dado que XMLHTTPRequest no sería fácil de leer (¿es XMLH TTP Request?) Y XMLhttpRequest rompería la convención de camelcase (¿es XM Lhttp Request?), La mejor opción sería mezclar case: XMLHttpRequest , que es en realidad lo que usó el W3C . Sin embargo, se desaconseja usar este tipo de nombres. Para este ejemplo, HTTPRequest sería un nombre mejor.

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 existe lo correcto o incorrecto. Solo intenta apegarte a una convención y asegúrate de que tus nombres sean legibles.

Answer 11

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

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

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

En caso de duda, solo ve a camelCase puro;)

parseXML está bien, parseXml también es camelCase

XMLHTTPRequest debe ser XmlHttpRequest o xmlHttpRequest no hay forma de ir con los acrónimos en mayúscula posteriores, definitivamente no está claro para todos los casos de prueba.

por ejemplo, cómo leer esta palabra HTTPSSLRequest , HTTP + SSL o HTTPS + SL (eso no significa nada sino ...), en ese caso, siga la convención de camel case y httpSslRequest o httpsSlRequest , tal vez ya no sea agradable , pero definitivamente es más claro.