Esistono buone tecniche o test per i tipi di nomi?

Per i nomi, ci sono sei tecniche che hanno dimostrato di funzionare per me:

1. dedica molto tempo alla creazione dei nomi
2. utilizza le recensioni del codice
3. non esitare a rinominare
4. dedica molto tempo alla creazione di nomi
5. utilizza le recensioni del codice
6. non esitare a rinominare

PS. Nel caso in cui la tua API sia pubblica, sopra vale prima - perché, sai,

"Public APIs, like diamonds, are forever. You have one chance to get it right so give it your best..." (Joshua Bloch, How to Design a Good API and Why it Matters)

Il mio test di base è se puoi descrivere la funzione della variabile usando solo parole dalla variabile:

e.g. if DomainSecurityMetadataProvider either "Provides Domain Security Metadata" or "Provides Metadata relating to Domain Security", it's good.

Tuttavia, ci sono sfumature che variano da persona a persona:

e.g. For me, original_team_code is the code for the original team, whereas for someone else it might be the original code for the team. My personal favourite one of these was "UnsafeLegacyMutex", which I couldn't help but read as "This is a Legacy Mutex which is Unsafe", rather than "This is a Mutex for ThreadUnsafe Legacy Code".

Quindi il mio test esteso è di scrivere la variabile su una bacheca / wiki / chat e fare in modo che la gente indovini cosa significa.

Are there any good techniques for choosing a well-meaning name for a component, or how to build a family of components without getting muddled names?

Non proprio.

Un consiglio, comunque, è di evitare la "voce passiva".

"DomainSecurityMetadataProvider" è passivo. Non c'è verbo, sono tutti nomi e nomi usati come aggettivi.

"ProvideMetadataForDomainSecurity" è più attivo. C'è un verbo.

La programmazione orientata agli oggetti è tutto (davvero) nome-verbo. Nome == oggetto. Verb == metodo. Quindi un nome di classe è generalmente molto "sostantivo". Rompere questa abitudine e iniziare a inserire i verbi è difficile.

Are there any simple tests that I can apply to a name to get a better feel for whether the name is "good", and should be more intuitive to others?

Sì. Hai definito un test eccellente nella tua domanda. Chiedi ad altre persone.

Nei tempi antichi la chiamavamo una "guida alla progettazione". E 'stato un grosso affare sudato in una metodologia cascata. Oggigiorno, con i metodi Agile, dovrebbe essere una normale collaborazione tra l'autore e gli utenti di una classe. Non (e non dovrebbe) richiedere molto tempo. Discutere del design (e dei nomi) prima di scrivere i test (e il codice) ridurrà il fattore di stupore e può prevenire i WTF.

Utilizzo di un thesaurus

Molto spesso farò riferimento a un dizionario dei sinonimi quando si fa un nuovo sviluppo per trovare parole appropriate per descrivere le mie classi e i miei metodi.

Classi che contengono principalmente la logica operativa

Tendo a nominare le classi che forniscono principalmente metodi operativi in una struttura di nomi-verbi come "EntityProvider", "EntityLocator", ecc.

Queste classi generalmente non contengono molto stato.

Classi che contengono lo stato

Le schermate dell'interfaccia utente e le entità di dati sono in genere stateful, quindi do semplicemente un nome a queste classi con un nome o un modello di aggettivo-nome.

Esempi: Person, Employee, CurrentEmployee, FormerEmployee

Classi di utilità

Le classi che contengono solo metodi statici sono generalmente considerate classi "utility", quindi le assegnerò costantemente con un suffisso "Utility".

Esempi: NetworkUtilities, FileUtilities

test

Non ho alcun test valido per decidere se qualcosa è mal chiamato, ma suggerirei di provare a usare un solo nome e / o un singolo verbo nel nome, quindi pensare se quel nome / verbo descrive accuratamente cosa stai nominando.

Se ritieni che ci sia molto altro per la classe / metodo che non viene catturato dal nome, allora quella classe / metodo potrebbe aver bisogno di essere refactored.

Alan Green e Jeff Attwood ha scritto sui mali delle classi di denominazione con il suffisso "Manager". Sostengono che il termine "Manager" è abusato ed è troppo vago per comunicare qualcosa di significativo. Devo essere d'accordo.

L'articolo di Jeff fornisce anche un elenco di linee guida suggerite dal codice completo di Steve McConnell.

variabili

Recentemente ho sperimentato nomi di variabili / parametri descrittivi più lunghi che incorporano preposizioni, come "Of", "By", "For", ecc. Alcuni esempi sono mostrati di seguito:

string firstNameOfEmployee;

string lastNameOfEmployee;

// here I nimbly avoid worrying about whether to call it "Id" or "ID" :)
int idOfEmployee;

decimal amountForDeposit;

Account accountForDeposit;

Trovo che questo funzioni correttamente con la funzione intellisense di Visual Studio che semplifica la digitazione di questi nomi lunghi. Trovo anche che ci sia meno duplicazione dei prefissi dei nomi delle variabili (ad esempio personID, personFirstName, personLastName vs. idOfPerson, firstNameOfPerson, lastNameOfPerson), fornendo un migliore "hash" che renda l'intellisense ancora più utile.

Then, when you've finally picked a name for the type you think describes what it's trying to do, your colleague asks "WTF does this DomainSecurityMetadataProvider actually do?"

Che tipo di nome ti aspetti per una classe complessa e specifica per il dominio? Questo è quanto di meglio si otterrà senza che il nome della tua classe diventi una frase (che farà credere a tutti che hai dato troppa responsabilità a una singola classe)

Prenderò in considerazione la possibilità di abbandonare il fornitore dal nome. Se menziona specificamente i metadati, tutti sanno già che stai usando la riflessione. Puoi renderlo una parola più concisa (o eventualmente cambiarla in un'altra parola - è più un consumatore che un fornitore di quello che hai scritto)

Usa metafore per descrivere parti del sistema. Non solo ti farà scoprire nuove analogie, faciliterà la denominazione.

(Sono consapevole che questo non è un esempio strong ma comunque) Ad esempio, puoi chiamare una variabile o un tipo come mailbox , che funge da coda per i messaggi ricevuti per una classe.

Una cosa su cui sono molto determinato è che i nomi dovrebbero MAI essere errati. Il miglior esempio, durante il ri-factoring, un sacco di codice è cambiato e alcune variabili hanno iniziato a riferirsi a qualcosa di diverso da quello che i loro nomi suggerivano.

Molto presto, un programmatore stava trascorrendo anni e utilizzando alcune costose chiamate al database cercando di ottenere alcuni dati che erano stati estratti e archiviati già. Ho ribattezzato tutto e all'improvviso abbiamo potuto rimuovere una tonnellata di logica complicata e buggata.

Si spera che i casi in cui devi riflettere così tanto sui nomi sono rari. Quando sorgono questi casi, scrivi semplicemente un paragrafo che spiega cosa fa la classe. Contrariamente ai commenti in funzione o al commento sul livello di funzione, lo scopo principale di una classe raramente cambia, pertanto il rischio che i commenti vengano superati è relativamente piccolo. Quindi hai il lusso di scrivere un paio di paragrafi o persino di disegnare ASCII per spiegare cosa fa la classe.