Convenzione di denominazione più corta per i tipi

Question

Sto sviluppando un framework e alcuni degli oggetti hanno nomi realmente lunghi. Non mi piace molto, ma nemmeno gli acronimi mi piacciono. Sto cercando di trovare un nome più breve per "EventModelSocket", fondamentalmente un wrapper attorno alla classe di socket .Net che implementa vari eventi, e metodi per inviare file, oggetti, ecc. Alcuni degli oggetti hanno nomi molto lunghi a causa di questo ad esempio "EventModelSocketObjectReceivedEventArgs".

Ho provato tutto da un dizionario dei sinonimi, a un dizionario di sedermi qui per ore a pensare.

Quando vi imbattete in situazioni come questa, qual è il modo migliore per nominare qualcosa?

Answer 1

Spingne un po 'nello spazio dei nomi.

Ad esempio:

EventModelSocketObjectReceivedEventArgs 

diventa

EventModel.Sockets.ReceivedEventArgs 

Answer 2

Bene, i nomi lunghi fanno male qualcosa?

(edit) altri due pensieri:

• uso var in C# 3.0 - che risparmia la metà della larghezza

• se si utilizza il tipo più volte in un file, si consideri un tipo alias se vi infastidisce:

  using Fred = Namespace.VeryLongNameThatIsBeingAnnoying;

Answer 3

io per primo l'uso della lunga nam e. Con intellisense digitando il nome non è così importante, a meno che non si stia utilizzando un monitor da 15 pollici.

Se dovessi ridurre il nome che potrei usare con EvtMdlSck, basta rendere il lavoro più breve ma ancora comprensibile. Anche se non è la mia preferenza.

Answer 4

Vorrei solo suggerire utilizzando la denominazione più concisa che descrive l'oggetto. Se lo fa EventModelSocketObjectReceivedEventArgs, andare avanti. I miei 2 centesimi.

Answer 5

Anni fa, quando ero in una classe di programmazione, il prof ha citato la statistica che un pezzo di codice è in genere letto 600 volte per ogni singola volta che è stato modificato. Oggi suppongo che questo non sia più vero, in particolare negli ambienti TDD in cui si verificano molti processi di refactoring. Tuttavia, penso che un dato pezzo di codice sia ancora letto molte più volte di quello che viene scritto. Pertanto, penso che la massima che dovremmo scrivere per la leggibilità sia ancora valida. La forma completa di una parola in un nome è più leggibile, poiché il cervello non deve fare la conversione. La comprensione è più veloce e più accurata.

Gli strumenti che abbiamo oggi rendono tutto questo facile con l'autocompletamento e simili. Per questo motivo, uso parole complete con nomi variabili ora e penso che sia un buon modo per andare.

Answer 6

Se hai bisogno di fare tanti sforzi per trovare un nome alternativo, hai già il nome corretto. I nomi oggetto/metodo/proprietà dovrebbero essere auto-documentanti. Se non descrivono il loro scopo esatto sono erroneamente definiti. Non c'è nulla di sbagliato nei nomi lunghi se danno la più chiara comprensione dello scopo di quell'oggetto.

In questa epoca di intellisense e di grandi monitor non c'è davvero alcuna scusa per non essere il più descrittivo possibile nella denominazione.

Answer 7

Alcune critiche sul naming ...

Perché il componente hanno la parola "modello" nel suo nome - isnt che un po 'ridondante.

Poiché il componente sembra essere un hub di messaggistica di qualche tipo, perché non includere il messaggio nel suo nome. Che dire di MessageSender.

Per risolvere il problema, vorrei creare un'interfaccia e assegnargli un nome generico come MessageSender e un'implementazione in cui è inclusa la tecnologia all'interno del nome come RandomFailingSocketMessageSender.

Se si vuole ottenere un buon esempio di questo dare un'occhiata alle librerie Java o .Net ..

da Java. interfaccia - classe/implementazioni ... Mappa - HashMap, LinkedHashMap. List - LinkedList

I dettagli relativi alla tecnologia o alla struttura utilizzata, ad es. Parole come "Socket" o forse per utilizzare un esempio forzato "MQSeries", non dovrebbero far parte del nome dell'interfaccia.

MessageSender sembra che IMHO riassuma lo scopo del componente. Sembra strano che la tua cosa che invia "file" e "eventi" non includa quelle due parole descrittive. Il materiale che usi nella tua denominazione è superfluo e IMHO non corrisponde alla tua descrizione del componente.

Answer 8

Non rimuovere le vocali o qualcosa di pazzo del genere.

Sono con le persone "bastone con il nome lungo".

Un pensiero è che se i nomi sono così scomodi, forse è necessario un ripensamento più profondo del sistema.

Answer 9

In generale, credo in nomi di classe che descrivono accuratamente la loro funzione, ed è giusto avere nomi lunghi. Se pensi che i nomi stiano davvero diventando lunghi, ciò che suggerirei è trovare un concetto ben noto al tuo team di programmazione e abbreviare quello. Quindi, se "Event Model Sockets" è un concetto che tutti conoscono, quindi abbrevili a EMS. Se hai un pacchetto che riguarda interamente Event Model Sockets, abbrevili a EMS in tutte le classi interne a quel pacchetto. La chiave qui è assicurarsi che il nome sia completo per chiunque non abbia familiarità con il concetto e abbreviato per chiunque lo sia.