Quali sono gli anti-schemi di denominazione? [chiuso]

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

• Le incoerenze . Se hai deciso di iniziare ogni nome di campo con un trattino basso, segui .
• Abbreviazioni di Ambiguos con vocali mancanti . Ho visto seriamente nomi di campi come cxtCtrlMngr . Difficilmente riesci a indovinare che cosa dovrebbe significare.
• Nomi di variabili troppo lunghi e dettagliati . ILoginAttemptRepository è fine e descrittivo - ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMapping è descrittivo, ma sicuramente non va bene.

Uno che mi capita spesso è, semplicemente, non usare alcun modello di denominazione. Tipicamente indicativo dell'ignoranza dello sviluppatore (che i pattern di denominazione sono una buona cosa ) e anche questo anti-pattern tende a violare grossolanamente SRP riempiendo tutti i tipi di metodi che sono in qualche modo legati a una classe in quella classe di per sé, quindi ad esempio una classe Customer ha proprietà, metodi CRUD, qualsiasi cosa che sia remotamente correlata a un cliente di cui necessita una parte dell'applicazione.

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

Bene, per prima cosa risposte semplici: digitare ungherese ( link , ha anche altre ottime idee. quando l'ungherese non è il male,   link )

Prefixing 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 distinguono tra interfacce e classi astratte - ma in Java, ad esempio, è sempre una cattiva idea.

Inoltre, non sono d'accordo con te sulla cosa Manager. A volte uso questo modello e significa che se provassi a chiamarlo in un altro modo, il nome non sarebbe più descrittivo di XxxxxManager. Ci sono alcuni compiti (non necessariamente complessi) che semplicemente 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 correttore ortografico sono impotente, provo a copiare tutti i nomi che creo in un word processor per la verifica, ma mi mancano sempre alcuni. Nel mio ultimo progetto ho scritto una grande parte della api e immagino di non aver eseguito il controllo ortografico la prima volta che ho usato la parola responce e ho pensato che fosse giusto perché nessuno me l'ha detto. Abbiamo avuto almeno 50 funzioni con risposta in esso. Una nuova persona è entrata nel team e ha chiesto perché usassimo la risposta mi sono sentito davvero stupido.

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

Per quanto mi riguarda devo essere d'accordo con Mike Baranczak, nomi come XxxController, XxxHandler è qualcosa che usiamo molto spesso. Per noi un Controller è qualcosa come un punto di accesso per qualcosa di "incapsulato", ad es. gestione delle transazioni, gestione degli errori imprevisti, chiamata a XxxHandler per eseguire il lavoro effettivo. Direi che 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 una squadra.

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

Ciò che personalmente non mi piace è, quando un metodo chiamato get ... o set ... è più di un semplice accessorio. 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 del fare molto. Ma la vita non è sempre solo in bianco e nero - ci sono situazioni in cui penso che sia ok - es. a causa di problemi di prestazioni (quando hai già i dati per verificare perché non li elaborano) ...

Personalmente sono anche un grande fan della notazione del sistema ungherese - la maggior parte delle volte si tratta di codice sorgente in un IDE ok. Ma spesso stai usando solo un editor o stai navigando sul 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 consitent - una convenzione subottimale - per me - è meglio che non avere una convenzione ...

Forse il peggior anti-pattern di denominazione è questo:

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

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

In codice come questo:

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

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

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

Il secondo peggiore è 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 es. [foo, bar] x [1,2,3] o [casa, perm] x [strada, città, stato]

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

Tautology (rhetoric), using different words to say the same thing even if the repetition does not provide clarity.

Incontro frequentemente librerie software con nomi generici come Library o Common . Indicano un design non ottimale: gli sviluppatori si sforzano di evitare la duplicazione del codice, ma senza alcun tentativo di creare un progetto scomposto sulla base della funzionalità.

Da Microsoft sull'assegnazione dei nomi, posso fornire questo elenco per i brutti nomi:

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