Convención de nomenclatura de Java con acrónimos [cerrado]


218

¿Cuál es el nombre correcto para la siguiente clase Java: DVDPlayero DvdPlayer?


93
Odio las siglas. DigitalVersatileDiscPlayerEs el camino a seguir.
Tom Hawtin - tackline

77
+1 a Tom por la broma. Encuentro útil esta pregunta si "correcto" se reinterpreta como "estándar" o "más típico". ¡La respuesta aceptada es genial!
Jon Coombs

66
Para mí tiene sentido pensar en tales siglas como una sola palabra y, como tal, sigo la convención y el uso DvdPlayer.
Daniel

77
La guía de estilo tiene lo siguiente que decir al respecto: "Formatee una abreviatura como una palabra si es parte de un nombre de clase más largo". , así DvdPlayeres el camino a seguir. (Y, para Tom, "Use palabras completas y evite usar abreviaturas a menos que la abreviatura se use más ampliamente que la forma larga" , y creo que "DVD" se usa más ampliamente que "Disco Versátil Digital" :-)
aioobe

Ciertamente quisiste decir "Discus", ¿no? :)
Ville Oikarinen

Respuestas:


237

Como parece que la respuesta es que no hay un estándar único para esto en Java, me gustaría señalar que las Pautas de diseño de .NET Framework sí lo especifican.

Ahora, antes de criticarme por estar fuera de tema, recuerde que las pautas de nomenclatura de clases para Java y .NET Framework son bastante similares, lo que hace que las pautas .NET sean útiles como referencia persuasiva.

Reglas generales

Ambas pautas recomiendan usar acrónimos solo cuando el acrónimo es ampliamente conocido y bien entendido. DVD o XML son excelentes ejemplos de esto, ya que si bien los reconocerá de inmediato, tomará un poco más de tiempo reconocer la versión expandida.

Abreviaturas

Las Pautas de .NET Framework recomiendan no usar abreviaturas (en lugar de acrónimos), excepto que se pueden usar dos abreviaturas comunes 'ID' y 'OK' en los identificadores. Cuando se usa una abreviatura, Idsiempre se usa mayúsculas y minúsculas, excepto la primera palabra de un identificador camelCase (a diferencia de un identificador PascalCase).

En Java, esta convención se sigue solo algunas veces. Echar un vistazo a cómo se mezcla la ortografía getIDy getIdse encuentran en el JCL. (Desplácese hasta la mitad de esa página). Sin embargo, en la versión Java 8 , getIdse usa cada vez más, lo que sugiere que la convención PascalCase se prefiere hoy en día. Es mejor evitar las abreviaturas por completo cuando sea posible.

Siglas cortas

Las Directrices de .NET Framework dicen que los acrónimos de dos letras como 'IO' deberían tener el mismo caso para ambas letras. Entonces, para los identificadores PascalCase (como el nombre de una clase) que obtendría DBRate, mientras que para un identificador camelCase (como una variable local) podría tener ioChannel.

Esto definitivamente parece ser la convención predominante en Java también.

Acrónimos largos

Las pautas de .NET Framework recomiendan que los acrónimos de tres letras o más usen mayúsculas y minúsculas para los identificadores PascalCase y camelCase, excepto la primera palabra de un identificador camelCase. Por lo tanto, para un nombre de clase que pueda tener XmlDocument, mientras que una variable local puede ser nombrada httpRequest.

Esta convención no siempre se sigue en Java. Los acrónimos de cuatro caracteres generalmente parecen usar mayúsculas y minúsculas, pero incluso el JCL no es consistente con los acrónimos de tres letras. La mayoría de ellos parecen estar en mayúscula, como 'URL', 'XML', 'SQL' y 'DOM', pero hay algunas excepciones como 'Jar'.

Conclusión

Para Java:

Para acrónimos de más de 4 letras, use mayúsculas y minúsculas. La biblioteca estándar hace esto, y tiene mucho sentido.

Para acrónimos de 3 letras, puede usar todo en mayúsculas como JCL, o puede usar mayúsculas y minúsculas como lo hace .NET Framework. De cualquier manera, sea consistente.

Para acrónimos de 2 letras, use todas las mayúsculas.

Para abreviaturas de 2 letras, Java realmente no tiene un estándar, pero sugiero usar mayúsculas y minúsculas, a menos que la coherencia con otros nombres haga que todas las mayúsculas se vean mejor.


11
Bien dicho, buen esfuerzo!
Eliran Malka

1
Me gusta esto, excepto que no es consistente tener CAPS para acrónimos de 3 y 2 letras. (Tal vez soy demasiado purista, pero veo la respuesta aceptada por razones prácticas. Además, está el factor de confusión).
Jon Coombs

1
@JCoombs: Bueno, la inconsistencia para 2 letras es algo IpAddressque parece terrible para muchas personas. Personalmente, cuando necesito escribir código Java, voy con mayúsculas y minúsculas para las siglas de 3 letras, dejando solo las dos letras como un caso especial.
Kevin Cathcart

55
¿Qué sucede si el nombre de su clase tiene múltiples siglas adyacentes de dos letras? Independientemente de lo que haga, se verá 'mal' - USGFCharset, UsGfCharset, US_GFCharset ...
Kevin

3
Muy buena respuesta. Pero personalmente no me gusta la idea de las pautas .NET de nombrar de manera diferente dependiendo de la longitud de las siglas y de si es una abreviatura o no. ¿A quién le importa y comprueba la longitud de un acrónimo? ¿O si es una abreviatura? Prefiero una regla general para nombrar. El problema surge cuando se usan bibliotecas de terceros con diferentes convenciones de cualquier regla que elija.
Amani Kilumanga

98

No hay una respuesta "correcta". Solo un conjunto de prácticas y convenciones que juegan mejor con sus otras herramientas.

Por eso lo prefiero DvdPlayer. Es más útil ya que en Eclipse puede hacer Ctrl+ Shift+ Ty elegir clases por la primera letra de cada palabra.

texto alternativo


19
oooo esa es una punta útil para el eclipse. ¡Gracias!
Peter Perháč

1
(+1) un buen consejo. eso responde la pregunta para mí :-)
Asaf

2
Solo "SIO" es suficiente para encontrar esa clase.
finnw

77
Esto también funciona en otros lugares de Eclipse, por ejemplo, autocompletar. ¿Tiene un método / variable llamado 'myDvdCoverImage'? - solo escriba mDCI Ctrl + Space
teabot

3
También hay algunos accesos directos ya establecidos, como sysout Ctrl + Space, le da System.out.println. lo mismo ocurre con (probar) y (para)
medopal

50

Los he visto a ambos utilizados en la naturaleza, y Sun parece ir por el DVDPlayerestilo. Sin DvdPlayerembargo, prefiero , porque de esa manera está claro dónde están los límites de la palabra, incluso si hay múltiples siglas consecutivas, como en HTTPURLConnection.


3
También es más rápido escribir de esta manera.
Ates Goral

66
Creo que "DVDPlayer" hace que los límites de la palabra sean más claros. "Dvd" no es una palabra, mientras que "DVD" es un acrónimo de las palabras "Disco versátil digital". Por lo tanto, los límites reales de las palabras en "DVD Player" están en "D", "V", "D" y "P".
Greg Brown

19
@GregBrown: Un DVD es un disco con un agujero, nadie excepto tú sabe su nombre completo, ni le importa. Y es mucho más práctico usar DvdPlayer.
Igor Rodriguez

44
@GregBrown: De hecho, es más práctico al menos en Eclipse, donde el reconocimiento de casos de camellos es un dolor con siglas: es decir, con DvdPlayer puede escribir "DP" y presionar Ctrl + 1 para elegir DvdPlayer, pero si tenías DVDPlayer tendrías que escribir "DVDP". Y es aún más molesto si es más largo. No me gustaría tener un UNESCOConnector en mi código. De todos modos es una cuestión de elección.
Igor Rodriguez

22
Otro buen ejemplo es HTTPSID: ¿me refería a HTTP SID o HTTPS ID? Por lo tanto, debería escribirse HttpSid o HttpsId respectivamente para explicar mejor el significado.
Oz Edri

37

Me gusta definir instancias individuales de clases de la siguiente manera:

Catalogue catalogue;
Person person;

Por lo tanto, si lo usara DVDPlayer, ¿cómo llamaría una instancia de eso? dVDPlayer? Por lo tanto, elegiría el DvdPlayernombre de la clase, para que pueda nombrar las instancias como dvdPlayer.


16
¿Qué tiene de malo DVDPlayer dvdPlayer;?
azz

99
@DerFlatulator ¿Qué tiene de malo? No importa cómo llegaste dvdPlayer, cuando regreses, obtendrás DvdPlayer.
maaartinus

55
@DerFlatulator: es una cuestión de automatización al convertir de UpperCamelCase a lowerCamelCase: tuve el problema al automatizar la asignación de Hibernate a snake_case: DvdPlayer -> dvd_playerpero DVDPlayer -> d_v_d_player. No hay forma de automatizar DVDPlayer a dvd_player.
pdem

3
@DerFlatulator: bien, gracias por la respuesta, funcionó en este caso. Pero todavía estoy convencido con la notación "DvdPlayer": ¿qué pasa con DVDRPGPlayer ?, debería convertirse a dvdRpgPlayer, no a dvdrpgPlayer.
pdem

2
También considere sus captadores y establecedores: getDvdPlayer()funciona mejor que getDVDPlayer(), por ejemplo, cuando se usa con JSP EL (por ejemplo, foo.dvdPlayer). Y si está nombrando a sus captadores con minúsculas en los acrónimos, es mejor mantener los nombres de sus clases iguales para mantener la coherencia y la previsibilidad.
daiscog

33

Algunos ejemplos de las clases JavaSE, apache commons y spring:

  • HttpURLConnection
  • HTTPAddress
  • UrlPathHelper
  • AopProxy
  • ISBNValidator

Entonces, realmente no importa.


3
Convenido. Solo sea consistente en su base de código.
JARC

2
No diría que no importa, aunque este no es exactamente un gran problema. Algunos de los usuarios encuentran que los estándares generalmente preferidos son muy útiles, incluso si no todos los demás son consistentes al seguirlos.
Jon Coombs

debería preferir SRSmás SoftwareRequirementSpecification?
Shantaram Tupe


10

Como otros han indicado, es una cosa de estilo que difiere entre proyectos. Los proyectos de Google como Guava y GWT prefieren el DvdPlayerestilo.

https://google.github.io/styleguide/javaguide.html#s5.3-camel-case


Un enlace más general de la convención de Google para el DvdPlayerestilo: google-styleguide.googlecode.com/svn/trunk/…
Stan Kurdziel

1
El enlace en la respuesta se ha movido a gwtproject.org/makinggwtbetter.html#codestyle El enlace que menciona @StanKurdziel se ha movido a google.github.io/styleguide/javaguide.html#s5.3-camel-case
Jeroen Wiert Pluimers

8

De los documentos de sun java :

Los nombres de clase deben ser sustantivos, en mayúsculas y minúsculas con la primera letra de cada palabra interna en mayúscula. Intenta mantener los nombres de tus clases simples y descriptivos. Use palabras completas: evite las siglas y abreviaturas (a menos que la abreviatura sea mucho más utilizada que la forma larga, como URL o HTML).


14
Eso realmente no dice nada sobre si debería ser mayúscula o camello.
DD.

@DD. Creo que para mí, los puntos "mucho más utilizados" usan mayúsculas para acrónimos relevantes (HTTP, GET, etc.) que para algunas palabras aleatorias específicas de negocios como DVD, MRI, MAGA, etc.
goelakash

3

DVDPlayer es el estándar, pero DvdPlayer no es raro.

Usted más a menudo que no ve getId. Probablemente se deba a que la identificación del pensamiento es un acortamiento de la "identidad". En realidad, son las iniciales del documento de identidad.

HttpURLConnectiona menudo se da como un ejemplo de convención mixta. Sin embargo, "http" usado como nombre de protocolo en una URL debe ser minúscula (aunque a menudo se acepta mayúscula).


2
No creo que esto sea realmente un estándar, pero probablemente sea el más común.
b.roth

Está en Sun Java Coding Standard, IIRC. Aunque no en el JLS.
Tom Hawtin - tackline

77
HyperTextTransferProtocolUniformResourceLocatorConnection
flybywire

2
Estoy bastante seguro de que la mayoría de las personas usan ID como una abreviatura de Identificador ... es decir, en una base de datos, la ID de la tabla se refiere al identificador de la tabla en el documento de identidad.
DD.

99
DVDPlayer definitivamente no es el estándar; incluso el JDK es muy inconsistente en su enfoque de esto.
Kevin Bourrillion

0

No hay "correctas", solo preferencias aquí.

Sun es consistente en la forma en que nombran las clases que contienen "URL" y "HTML", pero veo que HTTP usa mayúsculas y mayúsculas en los javadocs.

Personalmente, preferiría DvdPlayer.


Creo que el nombre del protocolo HTTP en las URL debe escribirse en minúsculas (aunque los navegadores pueden aceptarlo en mayúsculas).
Tom Hawtin - tackline
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.