acrónimos de la caja del camello?

Question

Esta pregunta puede parecer pedante o simplemente tonta, pero ¿cuál es su práctica para la carcasa de camello cuando se trata de acrónimos? ¿Insiste en que todo, incluso los acrónimos, deben estar revestidos de camello o hacen una excepción para los acrónimos? Las explicaciones también serían geniales. No estoy seguro de cómo esta práctica afecta a las características IDE (autocompletar) o cuáles son los estándares de la industria.

Answer 1

para C#, echa un vistazo a Microsoft's guidelines:

No capitalizar los dos personajes de acrónimos de dos caracteres, excepto la primera palabra de un identificador camello entubado .

una propiedad denominada DBRate es un ejemplo de un corto acrónimo (DB) se utiliza como la primera palabra de una identificador entubado-Pascal . Un parámetro denominado ioChannel es un ejemplo de un acrónimo corto (IO) utilizado como la primera palabra de un identificador camel-cassette.

No mayúscula sólo el primer carácter de siglas con tres o más caracteres , excepto la primera palabra de un identificador de camello entubado.

una clase llamada XmlWriter es un ejemplo de una larga sigla usada como la primera palabra de un identificador de entubado-Pascal. Un parámetro llamado htmlReader es un ejemplo de un acrónimo largo utilizado como la primera palabra de un identificador camel-cased .

no capitalizan cualquiera de los caracteres de las siglas, lo su longitud, al comienzo de un identificador de camello entubado .

un parámetro denominado xmlStream es un ejemplo de un acrónimo de largo (XML) utilizado como la primera palabra de una identificador de camello entubado. Un parámetro denominado dbServerName es un ejemplo de un acrónimo corto (db) utilizado como la primera palabra de un identificador camel-cassette.

Answer 2

No tenemos difícil regla & rápido, pero generalmente no acrónimos de camello. Algunos con más de tres letras son pero la mayoría no lo son.

Answer 3

preferencia personal.

Tiendo a hacerlo simplemente porque no se combina bien con otras palabras, como, XMLHTTPParser, en comparación con XmlHttpParser. Haz lo que te haga sentir bien, pero hazlo de una manera estándar.

Answer 4

Esto es lo que me gusta, y esto es para Java: las clases comienzan con mayúsculas, los campos con minúsculas y los acrónimos no afectan a eso.Esto nos lleva a las cosas que se ven así,

UrlConnection urlConnection; 

El problema es que si se intenta aplicar una regla en la que siempre mayúsculas siglas, o incluso la primera letra de un acrónimo, independientemente de que sea un campo o una clase de nombre, a hacer las cosas extrañas como,

URLConnection URLConnection; // huh? 

En otras palabras, el campo comienza con el artículo minúsculas contradice con una regla siglas en mayúsculas hipotético. No puedes aplicarlos a ambos.

Incluso el SDK Java tiene ejemplos de ambos, dentro de un único nombre genérico: HttpURLConnection. Se podría pensar que sería ya sea HTTPURLConnection o HttpUrlConnection.

Answer 5

En general, nuestras siglas se PascalCased o CamelCased ya que la mayoría han declarado.

Algunas excepciones:

• Si un acrónimo utilizado en un nombre de miembro es bien conocido en el negocio para el que se está escribiendo el software, y es un verdadero acrónimo (las letras mayúsculas forman una palabra del diccionario , a diferencia de una inicialización como XML), a menudo lo capitalizamos para evitar confusiones con la palabra del diccionario.

• Algunas veces en ORMs que trabajan contra DB existentes, acabo de nombrar la variable mapeada lo mismo que la columna DB, mayúsculas y todo, en lugar de tener que mapear FdicId => FDICID explícitamente en una base de datos sensible a mayúsculas y minúsculas. Esto tiene su lado negativo, como futuros desarrolladores pueden romper en silencio funcionalidad si se sienten con más fuerza que yo que debe ser entubado correctamente, pero no sabía qué.

• ID es un poco de un flip-flopper cuando se utiliza en el extremo de un nombre de miembro; Ya sea ID o Id depende del desarrollador que escribe el primer miembro de esa clase o espacio de nombres, y rara vez se revisan.

Answer 6

En general, el tratamiento de siglas el mismo que el caso general palabra es el más intuitivo, por las siguientes razones.

1. Ayuda a evitar la memorización de un montón de reglas especiales (ejemplo de ello, las directrices MS arriba)
2. El minúsculas y mayúsculas de términos específicos pueden cambiar con el tiempo o entre las interpretaciones personales como con posix, unix, regex, radar, scuba, laser y email
3. de otro modo, puede obtener visualmente torpe cuando se necesita para hacer frente a (y/o combinar) términos tecnológicos como miniiOSLayout, SSHHTTPSSession, CPUURLLinkC y schemaeBay (concedieron estas especi ejemplos FIC es poco probable, que ayudan a ilustrar el problema)
4. que elimina cierta confusión si el idioma utiliza diferentes casos para diferentes cosas, como la capitalización AClassName pero no anObjectName

Sí, httpUrl parece tonto. Pero cuanto más codifique, más probable es que se dé cuenta de los puntos anteriores por su cuenta. Y si bien no es un gran negocio en sí mismo, muchas cosas pequeñas pueden acumularse y crear frustración con su trabajo.

Answer 7

Depende de la longitud de los acrónimos también.

DB ---> ve decente

openDBConnection 

HTTP ---> parece extraño

openHTTPCConnection 

Aparte de reglas:

• legibilidad importa mucho para mí.

• La consistencia muestra su esfuerzo en la programación.

Por lo tanto, hazlo consistente y legible.