¿Qué convención de nomenclatura de paquetes utiliza para proyectos personales / hobby en Java?


143

Ya estoy familiarizado con la convención de nomenclatura de paquetes estándar de Java de usar un nombre de dominio para crear un nombre de paquete único (es decir, paquete com.stackoverflow.widgets). Sin embargo, nunca he visto ninguna recomendación sobre cómo elegir nombres de paquetes para proyectos personales. Supongo que es porque esto es realmente una cuestión de gusto personal.

Entonces, ¿cómo elige los nombres de los paquetes para proyectos personales que nunca llegarán a la producción (es posible que esté experimentando con un nuevo marco en su tiempo libre). Suponiendo que no tiene un sitio web personal cuyo dominio puede usar para crear la estructura de su paquete, ¿qué hace (o haría)? ¿Tiene un sistema lógico para generar nuevos nombres de paquetes para proyectos de pasatiempo, o simplemente usa nombres de paquetes desechables simples mypackage?

Como tengo curiosidad por ver qué piensan las diferentes personas sobre esto, he hecho de este un wiki comunitario.

Personalmente, nunca lo he pensado mucho, pero quería jugar con Wicket esta noche y se me ocurrió que no tengo una idea clara de cómo quiero organizar mis proyectos de pasatiempo. Una convención de nomenclatura de paquetes distinta y separada para proyectos de pasatiempos (en mi opinión, al menos) serviría como una buena manera de mantener el código personal y relacionado con el trabajo claramente separado el uno del otro.

Estaba pensando en una simple convención de nomenclatura jerárquica, para mantener la fuente de mis proyectos personales en una sola carpeta raíz:

  • Utilizar myprojectscomo la carpeta raíz
  • Agregar el nombre del proyecto
  • Agregue cualquier nombre de subpaquete adicional

Entonces, mi proyecto Wicket estaría en el paquete myprojects.learningwickety las pruebas unitarias estarían en el paquete myprojects.learningwicket.tests(por ejemplo).


1
Común, consiga un dominio personal (firstname-lastname.net) y úselo como nombre de paquete. El propósito del paquete es ser globalmente único, por lo que mis proyectos realmente no lo cortan.
Vladimir Dyuzhev

55
Usar un dominio .onion también es una opción (como onion.duskgytldkxiuqc6.packagename). Mientras la clave privada permanezca secreta, usted tiene el control del nombre de dominio. Por lo tanto, es gratis registrarse (generar) y es permanente (a diferencia de los dominios convencionales). Se ajusta a la letra de la convención Java, y te identifica de manera única.
Sastanin

14
Siempre puede crear una cuenta de GitHub y usar io.github.username. *.
Bardi Harborow

2
@BardiHarborow gracias, utilicé tu sugerencia.
Nick Volynkin

3
@GabrielBB, GitHub Pages le permite alojar sitios HTML y Jekyll en yourusername.github.io y, por lo tanto, los subdominios de github.io están más "garantizados" para corresponder a los usuarios de GitHub que los subdominios de github.com (que podrían usarse para uso interno). Proyectos de GitHub en cualquier momento).
Bardi Harborow

Respuestas:


49

Si solo está haciendo proyectos personales donde nadie más usará el código, entonces puede inventar un nombre de paquete que le guste. Sin embargo, no invente algo que comience con com.u net.otro dominio de nivel superior, porque eso implicaría que es el propietario del nombre de dominio (es decir, usarlo com.johncomo nombre de su paquete solo porque su nombre sea John no es una buena idea) .

Si va a dar el código a alguien más, debe usar un nombre de paquete único a nivel mundial, lo que según las convenciones de Java significa que debe registrarse y usar un nombre de dominio.


1
Entonces, si quiero abordar el nombre del paquete, ¿ com.xyzdebería registrarse este nombre en algún lugar? PD xyzes mi cliente.
Prasad

9
Me pregunto si puedo usar mi id de github para eso y el dominio de github. Por ejemplo com.github.mygithubid.myproject?
Kirill G.

2
@KirillG. Recomendaría no hacerlo, ya que las ID de GitHub se pueden cambiar en cualquier momento, cualquier cantidad de veces. De acuerdo, cualquier dominio puede cambiar, pero no tan fácil o tan a menudo (normalmente no de todos modos). Aunque supongo que está bien para proyectos de hobby.
Sara

26

Solo uso mis iniciales: fg.nameofproject.etc

Reduce la tipificación. Puede tener el prefijo en cualquier momento con sf.net o com. u org. o com.google ..

Como el proyecto es personal, es especial, al igual que su camisa de regalo personalizada recién prensada, se sentirá bien.


42
bond.james.007
Haga clic en Upvote

19
@Haga clic de acuerdo con las pautas que serían bond.james._007: no tiene el mismo
tono

20
pmurray_at_bigpond_dot_com.project.package

2
+1. Inteligente. Esto le proporciona un nombre de paquete único e identifica al autor de una vez.
Mike Spross

19

<sarcasm>Bah. Cualquier programador que se respete tendría su propio nombre de dominio. Esta es claramente una pregunta capciosa. ¡Todos tienen su propio nombre de dominio personal! </sarcasm>:-)

Ok, con toda seriedad, comprar un nombre de dominio personalizado es probablemente la opción más fácil. Por aproximadamente $ 10 al año, puede encontrar proveedores acreditados para alojar el dominio y reenviar el correo electrónico.


18
Por extraño que parezca, esto también aumentará su confianza en sí mismo.
James

26
Buena respuesta, pero un programador principiante probablemente no quiera comprar un sitio web solo para seguir un sitio web tutorial o un video sobre cómo crear una GUI con un botón de cierre.
Jochem Kuijpers el

17

Almaceno la mayoría de mis proyectos de hobby en Google Code, por lo que sólo tiene que utilizar el sitio del proyecto como el nombre del paquete: com.googlecode.donkirkby.someproject.


8
¿Cuán ciegos podríamos haber estado para no ver la locura de nuestras acciones?
Joey Sabey

1
¿Echas de menos Google Code, @Joey? La mayoría de las veces he usado GitHub durante los últimos años, por lo que tuve que mover algunos de mis proyectos anteriores de Google Code antes de que se cerraran.
Don Kirkby

Entonces, ¿cambiaste el nombre de los paquetes, mantuviste los nombres de googlecode o ...?
serv-inc

1
No he usado ninguno de los códigos antiguos desde que lo moví, @ serv-inc. Cualquiera de las opciones funcionaría.
Don Kirkby

3

mi nombre es anjan

usualmente uso com.anjan

Tengo una compañía de fantasía propia, a veces uso eso

la tradición con sourceforge (como se muestra en hibernación y otros paquetes) es net.sf. *

entonces, dependiendo de tu estado de ánimo, puedes ir con eso.


13
A menos que también sea propietario de anjan.com , creo que está terriblemente equivocado al hacerlo.
Fredrik

77
@Fredrick, por suerte, parece que anjan.com no lanzará ninguna biblioteca en el corto plazo.
corsiKa

1
@corsiKa: tienes razón, mientras no publique nada, estoy bien. :-)
anjanb

3
@anjanb Bueno, fui al sitio web de ellos. Hacen comida para mascotas. No soy un experto, pero la mayoría de las compañías de alimentos para mascotas no lanzan muchas bibliotecas de software =)
corsiKa

3

Creo que lo tienes resuelto. La tentación de evitar aquí es no molestarse con un nombre de paquete en absoluto. Es fácil guardar algunas pulsaciones de teclas porque "solo estoy escribiendo un código de prueba". Pero luego el código se vuelve bueno, útil y grande, y luego te das cuenta de que tienes un comienzo sólido para lo que puede ser una biblioteca o aplicación de larga duración. Puede que no sea una biblioteca o una aplicación que alguna vez abandone su red doméstica, pero el punto es que no ha pensado en el futuro. Ese es el fantasma de Dinamarca de la informática: siempre piense en el futuro, aunque sea un poco.

La convención de nomenclatura que uso para mi código de pasatiempo es muy parecida a la tuya. Tengo un directorio de nivel superior llamado "futura" (razones largas y aburridas por las que surgió ese nombre) del que cuelga todo mi código. Intento y organizo mi código en bibliotecas de paquetes, incluso si podría ser una clase o paquete que nunca uso para otro proyecto. Coloco todas las aplicaciones (es decir, cualquier cosa que tenga un vacío principal (String [] args) en la clase) en la carpeta futura.app. *. También trato de imitar los nombres de paquetes estándar de la biblioteca de Java para mi propio código, aunque en un par de casos violé la convención debido a mis propios gustos (es decir, futura.inet para Internet, no simplemente socket, código y futuras colecciones para -utilizar cosas.) Parafraseando a David Mamet: Siempre se genérico. ¡Sé siempre genérico!

Por la atención que solía publicar la pregunta, sospecho que también está de acuerdo con mi último punto: no tiene que tratar el pirateo de aficionados como un proyecto de nivel empresarial, pero si aporta algo de esa disciplina al juego local, El hobby es aún más gratificante.


2

Uso mi URL de OpenID y luego agrego el nombre de mi proyecto. por ejemplo, com.myopenid.cd1.twitteres el paquete raíz de un cliente de Twitter que he estado desarrollando.


Me gustó esto, pero luego me di cuenta de que ya no existe. :( janrain.com/myopenid-service-ends "A partir del 1 de febrero de 2014, el servicio MyOpenID se ha desactivado".
successhawk


1

Solo uso mi nombre: apellido.iniciales.xxx, como una buena relación entre la brevedad y la prevención de colisiones. Supuse que eso proporcionaría un espacio de nombre libre de colisiones razonable si alguna vez decidiera publicar el código públicamente. También tengo un pequeño programa que he escrito que puede volver a empaquetar árboles de directorios completos, así que pensé que si alguna vez tuviera que volver a empaquetar para publicarlo es bastante indoloro ... por lo tanto, no perdí demasiado tiempo de sueño.

Después del apellido.initials.xxx, utilizo cualquiera de las aplicaciones para paquetes de aplicaciones, lib para paquetes de biblioteca y tst para cosas con las que estoy experimentando.


1

¿Qué opinas sobre lastname.firstname.project ??? como luz.marlon.project?


16
Eso podría funcionar para usted, pero John Smith y Bob Jones podrían tener conflictos cuando quieran lanzar su código algún día.
Bill el lagarto

0

Pensé en hacer esta misma pregunta. Hasta ahora he usado el prefijo com.tehvan, aunque en realidad no tengo una compañía.

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.