Convenzione di denominazione degli artefatti

Question

Stiamo facendo un grande progetto su OSGi e aggiungendo alcuni moduli commons.C'è qualche discussione sul nome dell'artefatto.

Quindi, una possibilità quando si nomina il modulo è ad esempio:

cmns-definitions (per definizioni comuni), un altro è cmns-definition, ancora un altro è cmns-def.Questo ha qualche effetto anche sul nome del pacchetto.Ora è xx.xxx.xxx.xxx.xxx.commons.definitions, se cambiando a cmns-def sarebbe xx.xxx.xxx.xxx.xxx.commons.def.

All'interno di questo pacchetto ci saranno classi come enumerazioni e altre definizioni da utilizzare in tutto il sistema.

Personalmente mi appoggio a cmns-definitions poiché non c'è solo 1 definizione all'interno del pacchetto.Altre persone sottolineano che java.util non ha solo 1 utilità lì per esempio.Ancora, java.util è un abbreviazione per me.Può significare utilità java o utilità java.La stessa cosa accade con commons-lang.

Come chiameresti il pacchetto?Perché scegliere questo nome?

1. cmns-definitions
2. cmns-definition
3. cmns-def

Domanda bonus:Come nominare qualcosa di simile cmns-exceptions?E 'cosi' che lo chiamo.Lo chiameresti cmns-xcpt?

MODIFICARE:

Sto gettando i miei pensieri su questo nella speranza di essere confermato o contraddetto.Se potete, per favore fatelo.

Secondo quello che penso, il motivo di fondo per cui si nomina qualcosa è quello di rendere più facile capire cosa c'è dentro.O, secondo Peter Kriens, per rendere più facile da ricordare e di essere in grado di automatizzare i processi tramite modelli.Entrambi sono argomenti validi.

Il mio ragionamento è il seguente in termini di modello:

1) Quando si verifica una sostantivazione ed è ben nota nel settore, seguila sulla tua denominazione.
Ad esempio:"caratteristiche" è un caso su questo.Abbiamo un modulo chiamato cmns-features.Questo significa che abbiamo molte funzionalità su questo modulo?No.Significa "il modulo che implementa il file "features" da Apache karaf".
"commons "è una sostantivazione di" comune " ben accettata nel settore.Non significa "molti comuni".Significa "Codice comune".

Se vedo extr-commons come nome di un modulo, so che contiene codice comune per extr (in questo caso estrazione), ad esempio.

2) Quando una quantità di classi all'interno del modulo sta cooperando per dare un significato distinto "uno e uno solo" al tutto, usa la forma singolare per nominarlo.

La maggior parte dei moduli sono inclusi qui.Se nomino qualcosa cmns-persistence-jpa, intendo che qualsiasi classe all'interno coopera insieme per fornire l'implementazione jpa di cmns-persistence-api.Non mi aspetto 2 implementazioni al suo interno, ma in realtà una miriade di classi che insieme fanno una implementazione.Chiarissimo per me.No?

3) Quando un raggruppamento di classi è fatto con il solo scopo di raccogliere classi per affinità, ma le classi non cooperano insieme senza scopo, usa il plurale.

Ecco il caso, ad esempio, delle definizioni cmn (enumerazioni utilizzate dall'intero sistema).

In alternativa, l'uso di un'abbreviazione elude il problema, ad es.cmns-def che può anche essere "interpretato espanso" da un lettore umano a cmns-definizioni.Molte persone usano anche "xxxx-util" che significa xxxx-utilities.

Ancora una terza opzione può essere utilizzata per mettere insieme le cose, usando un nome che di per sé significa una pluralizzazione.La parola " api "viene in mente, ma qualsiasi parola che pluralizza qualcosa farebbe, come"pack".

Il supporto a questi casi (3) sono moduli ben noti come commons-collections (usando il plurale) o commons-dbcp (usando l'abbreviazione) o commons-lang (di nuovo abbreviazione) e tutto ciò che utilizza api per raggruppare le classi per affinità.

Di apache:
commons-collections - > molte potenti strutture di dati che accelerano lo sviluppo delle applicazioni Java più significative
commons-lang - > host di utilità di supporto per java.lang API
commons-dbcp - > pacchetto di diversi pool di connessioni al database

Answer 1

"è solo un nome ...'

Trovo nella mia lunga carriera che questi nomi possono fare un'enorme differenza in termini di produttività.Non credo che fa la differenza se si utilizza definizione, definizione, o def finché sei coerente e usi modelli nel nome che sono facili da ricordare e possono essere utilizzati per automatizzare i processi.Una build basata su uno schema di denominazione coerente è infinitamente più facile da lavorare rispetto a una build con nomi "nice human display" che sono ad-hoc e non hanno uno schema distinguibile.

Se si utilizzano modelli, i nomi tendono a diventare più brevi.Ora le persone che lavorano con questi nomi di solito trascorrono molto tempo con loro.Quindi la loro leggibilità non è altrettanto importante del loro valore mnemonico.Si scopre che le abbreviazioni di 3 o 4 caratteri sono sorprendentemente potenti.Uno dei motivi è che funzionano bene è che c'è solo una possibile abbreviazione, mentre se si va più a lungo ci sono molti candidati.

In ogni caso, la maggior parte delle parti di importazione è la coerenza complessiva.Fortuna.

Answer 2

definitions (o def o definition) è un brutto nome perché non ha alcuna semantica per un lettore.Sei in un mondo orientato agli oggetti (suppongo) - prova a seguire le sue convenzioni e principi.I moduli in Maven dovrebbero prendere il nome dalla più grande "astrazione" che contengono."Definizione" è una forma, non un significato.

La tua domanda è simile a:"Quale nome di classe è migliore FileUtilities o FileUtils".Risposta:nessuno.

Answer 3

Fondamentalmente quello che fai con le definizioni e le eccezioni è fornire una sorta di API per gli altri moduli.Quindi propongo di combinare definizioni, eccezioni e aggiungere interfacce ad esso.Quindi ha senso chiamarlo tutto cmns-api.Normalmente preferisco i nomi singolari in quanto sono più brevi, ma sei libero di decidere in quanto è solo un nome.