Quali anti-pattern di denominazione esistono? [chiuso]

Ci sono alcuni nomi, in cui se ti ritrovi a cercare quei nomi, sai che hai già incasinato qualcosa.

Per esempio:

XxxManager
Questo è negativo perché una classe dovrebbe descrivere ciò che fa la classe. Se la parola più specifica che puoi trovare per quello che fa la classe è "gestisci", allora la classe è troppo grande.

Quali altri anti-pattern di denominazione esistono?

Per chiarire, non sto chiedendo "quali nomi sono cattivi" - questa domanda è del tutto soggettiva e non c'è modo di rispondere. Sto chiedendo "quali nomi indicano problemi generali di progettazione con il sistema". Cioè, se ti ritrovi a voler chiamare un componente Xyz, questo probabilmente indica che il componente è mal concesso. Nota anche qui che ci sono eccezioni ad ogni regola: sto solo cercando bandiere di avvertimento per quando ho davvero bisogno di fermarmi e ripensare un disegno.

I seguenti schemi di denominazione sono correlati a .NET e, in particolare, a C #:

• Incoerenze . Se hai deciso di iniziare ogni nome di campo con un carattere di sottolineatura iniziale, mantienilo .
• Abbreviazioni di Ambiguos con vocali mancanti . Ho visto seriamente nomi di campi come cxtCtrlMngr. Difficilmente puoi indovinare cosa dovrebbe significare.
• Nomi di variabili troppo lunghi e dettagliati . ILoginAttemptRepositoryva bene e descrittivo - ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMappingè descrittivo, ma sicuramente non va bene.

Uno che mi capita spesso di incontrare è, semplicemente, non usare alcun modello di denominazione. Tipicamente indicativo dell'ignoranza degli sviluppatori (che i modelli di denominazione sono una buona cosa ) e anche questo anti-modello tende a violare gravemente SRP inserendo tutti i tipi di metodi che sono in qualche modo correlati a una classe in quella classe stessa, quindi ad esempio un cliente La classe ha proprietà, metodi CRUD, qualsiasi cosa in remoto correlata a un Cliente di cui necessita una parte dell'applicazione.

Aggiungerò anche che l'uso di "Engine" come suffisso equivale all'utilizzo di "Manager". È molto vago e una classe chiamata XxxEnginetende ad essere ciò che equivale a un modulo in stile VB contenente un sacco di metodi, quindi è in un punto "facile da usare", senza alcuna conoscenza o idea di programmazione orientata agli oggetti.

Bene, prima le risposte semplici: digitare hungarian ( http://mindprod.com/jgloss/unmainnaming.html , ha anche altre grandi idee. Una visione più equilibrata di quando l'ungherese non è cattivo, http://www.joelonsoftware.com /articles/Wrong.html )

Prefisso un 'I' al nome di un'interfaccia o 'Abstract' al nome di una classe astratta. Questo potrebbe essere scusabile in linguaggi che non hanno il concetto di classi astratte o che non fanno distinzione tra interfacce e classi astratte - ma in Java, ad esempio, è sempre una cattiva idea.

Inoltre, non sono d'accordo con te sull'aspetto Manager. Uso quel modello a volte, e significa solo che se provassi a nominarlo con qualcos'altro, il nome non sarebbe più descrittivo di XxxxxManager. Ci sono alcuni compiti (non necessariamente complessi) che non possono essere riassunti in modo ordinato in una o due parole.

Speeling:

Ho una disabilità pendente e non posso fare lo spelling. Senza il controllo ortografico sono impotente, cerco di copiare tutti i nomi che creo su un elaboratore di testi per la verifica, ma mi mancano sempre alcuni. Nel mio ultimo progetto ho scritto gran parte dell'API e immagino di non aver controllato l'ortografia la prima volta che ho usato la parola responce e ho pensato che fosse giusto perché nessuno me lo ha detto. Avevamo almeno 50 funzioni con risposta in esso. Una nuova persona è entrata nella squadra e ha chiesto perché usiamo la risposta, mi sono sentito veramente stupido.

Beh, temo che le mie opinioni siano un po 'controverse. Ma proviamo ...

Per quanto mi riguarda, sono d'accordo con Mike Baranczak, nomi come XxxController, XxxHandler è qualcosa che usiamo molto spesso. Per noi un controller è qualcosa di simile a un punto di entrata per qualcosa di "incapsulato", ad esempio la gestione delle transazioni, la gestione di errori imprevisti, la chiamata a XxxHandler per svolgere il lavoro effettivo. Direi che un XxxManager è sinonimo di controller. Penso che sia importante non utilizzare Manager in un caso e Controller in un altro. Essere coerenti è molto importante se lavori in gruppo.

Sarebbe davvero difficile o forse nemmeno possibile trovare nomi migliori per cose come questa. Xxx dovrebbe essere ben scelto per rendere la situazione più chiara.

Quello che personalmente non mi piace è quando un metodo chiamato get ... o set ... è molto più di un semplice accessor. Mi piace det ... per determinare.

Un'altra cosa, che mi viene in mente: secondo lo zio Bob. Un "E" nel nome di un metodo è un segno di fare molto. Ma la vita non è sempre solo in bianco e nero - ci sono situazioni in cui penso che sia ok - ad es. a causa di problemi di prestazioni (quando disponi già dei dati per verificare perché non elaborarli) ...

Personalmente sono anche un grande fan della notazione ungherese dei sistemi - il più delle volte hai a che fare con il codice sorgente in un IDE ok. Ma spesso stai usando solo un editor o stai navigando nel repository in un browser. Uno svantaggio potrebbe essere il supporto degli strumenti a causa dei prefissi di tipo ...

Penso che la cosa più importante sia essere coerenti - una convenzione non ottimale - per me - è meglio che non avere una convenzione ...

Forse il peggior nome anti-pattern è questo:

create table stuff(..., foo1 string, bar1 string,
                        foo2 string, bar2 string, 
                        foo3 string, bar3 string, ...)

Abbiamo un elenco di tre elementi di coppie [foo, bar]. Se avremo bisogno di un quarto, dovremo aggiungere nuove colonne alla tabella.

Portando a codice come questo:

'SELECT foo' + i + ', bar' + i + ' FROM stuff'

Una tabella separata dovrebbe essere creata con colonne foo e bar e collegata alla tabella roba:

create table fubar(foo string, bar string, stuff_id long)

Il secondo peggio è questo:

class Student {
  ...
  String homeStreet;
  String homeCity;
  String homeState;
  String permStreet;
  String permCity;    
  String permState;
  ...
}

Qui abbiamo sei campi invece di due istanze di una classe Address.

Questo anti-pattern è contrassegnato da una serie di nomi in due parti che elencano ogni combinazione di due set, ad esempio [foo, bar] x [1,2,3] o [home, perm] x [via, città, stato]

Qualsiasi denominazione di classe o interfaccia che è una tautologia è una cattiva, non solo in Java di cui parla il collegamento, ma in qualsiasi lingua.

Tautologia (retorica), usando parole diverse per dire la stessa cosa anche se la ripetizione non fornisce chiarezza.

Incontro spesso librerie software con nomi generici come Libraryo Common. Indicano un design non ottimale: gli sviluppatori si sforzano di evitare la duplicazione del codice ma senza alcun tentativo di creare un design decomposto in base alla funzionalità.

Da Microsoft sulla denominazione, posso fornire questo elenco per i nomi errati:

1. Non sono semantici, il che significa che hanno nomi che invece di enfatizzare ciò che fa, enfatizzano la tecnologia che utilizza o il modello su cui si basa .
2. Non seguono una coerenza sintattica. Ad esempio, una parte dei nomi ha un involucro di cammello, mentre l'altra parte ha un involucro di pascal.
3. Sono abbreviazioni, che sono difficili da capire, come ScrollableX invece di CanScrollHorizontally
4. Sono scelti in modo tale da incasinare le parole chiave di quell'ambiente.