Qualcun altro trova le classi e i metodi di denominazione una delle parti più difficili della programmazione? [chiuso]

Quindi sto lavorando a questa classe che dovrebbe richiedere la documentazione di aiuto da un fornitore attraverso un servizio web. Provo a chiamarlo DocumentRetriever, VendorDocRequester, DocGetter, ma semplicemente non suonano bene. Ho finito per sfogliare il dizionario.com per mezz'ora cercando di trovare una parola adeguata.

Iniziare a programmare con nomi cattivi è come avere una brutta giornata al mattino, il resto della giornata va in discesa da lì. Sentimi?

Quello che stai facendo ora va bene, e ti consiglio vivamente di attenersi alla tua sintassi corrente, essendo:

contesto + verbo + come

Uso questo metodo per nominare funzioni / metodi, processi memorizzati in SQL, ecc. Mantenendo questa sintassi, i pannelli Intellisense / codice manterranno molto più accurati. Quindi vuoi EmployeeGetByID () EmployeeAdd (), EmployeeDeleteByID (). Quando usi una sintassi più grammaticalmente corretta come GetEmployee (), AddEmployee () noterai che questo diventa davvero disordinato se hai più Gets nella stessa classe in cui le cose non correlate verranno raggruppate insieme.

Mi assomiglio a nominare i file con le date, vuoi dire 2009-01-07.log non 1-7-2009.log perché dopo averne un mucchio, l'ordine diventa totalmente inutile.

Una lezione che ho imparato è che se non riesci a trovare un nome per una classe, c'è quasi sempre qualcosa di sbagliato in quella classe:

• non ne hai bisogno
• fa troppo

Una buona convenzione di denominazione dovrebbe ridurre al minimo il numero di nomi possibili che è possibile utilizzare per una determinata variabile, classe, metodo o funzione. Se esiste un solo nome possibile, non avrai mai problemi a ricordarlo.

Per le funzioni e per le classi singleton, scruto la funzione per vedere se la sua funzione di base è quella di trasformare un tipo di cosa in un altro tipo di cosa. Sto usando quel termine molto liberamente, ma scoprirai che un numero ENORME di funzioni che scrivi essenzialmente prende qualcosa in una forma e produce qualcosa in un'altra forma.

Nel tuo caso sembra che la tua classe trasformi un URL in un documento. È un po 'strano pensarlo in quel modo, ma perfettamente corretto, e quando inizi a cercare questo schema, lo vedrai ovunque.

Quando trovo questo modello, chiamo sempre la funzione x Fromy .

Dato che la tua funzione trasforma un URL in un documento, lo nominerei

DocumentFromUrl

Questo modello è straordinariamente comune. Per esempio:

atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine

Puoi anche usarlo UrlToDocumentse ti senti più a tuo agio con quell'ordine. Sia che tu dici x Fromy o y Tox è probabilmente una questione di gusti, ma io preferisco l' Fromordine perché in questo modo l'inizio del nome della funzione che si dice già che tipo restituisce.

Scegli una convenzione e attenersi ad essa. Se stai attento a usare gli stessi nomi dei nomi delle tue classi nelle tue funzioni x Fromy , sarà molto più facile ricordare quali nomi hai usato. Naturalmente, questo modello non funziona per tutto, ma funziona dove stai scrivendo codice che può essere considerato "funzionale".

A volte non esiste un buon nome per una classe o un metodo, succede a tutti noi. Spesso, tuttavia, l'incapacità di trovare un nome può essere un suggerimento per qualcosa di sbagliato nel tuo design. Il tuo metodo ha troppe responsabilità? La tua classe incapsula un'idea coerente?

Discussione 1:

function programming_job(){
    while (i make classes){
         Give each class a name quickly; always fairly long and descriptive.
         Implement and test each class to see what they really are. 
         while (not satisfied){
            Re-visit each class and make small adjustments 
         }
    }
}

Discussione 2:

while(true){
      if (any code smells bad){
           rework, rename until at least somewhat better
      }
}

Non c'è Thread.sleep (...) da nessuna parte qui.

Passo anche molto tempo a preoccuparmi dei nomi di tutto ciò che può essere dato un nome durante la programmazione. Direi che paga molto bene però. A volte quando sono bloccato lo lascio per un po 'e durante una pausa caffè chiedo un po' in giro se qualcuno ha un buon suggerimento.

Per la tua classe, suggerirei VendorHelpDocRequester.

Il libro Codice completo di Steve Mcconnell ha un bel capitolo sulla denominazione di variabili / classi / funzioni / ...

Penso che questo sia un effetto collaterale.

Non è la vera denominazione che è difficile. La cosa difficile è che il processo di denominazione ti fa affrontare il fatto orribile che non hai idea di cosa diavolo stai facendo.

In realtà ho appena sentito questa citazione ieri, attraverso Signal vs. Noise blog di 37Signals, e sono sicuramente d'accordo:

"Ci sono solo due cose difficili in Informatica: invalidare la cache e denominare le cose." - Phil Karlton

È bello che sia difficile. Ti costringe a pensare al problema e a ciò che la classe dovrebbe effettivamente fare. I buoni nomi possono aiutare a portare a un buon design.

Concordato. Mi piace mantenere i nomi e le variabili dei miei tipi il più descrittivi possibile senza essere troppo orribilmente lunghi, ma a volte c'è solo un certo concetto per il quale non puoi trovare una buona parola.

In quel caso, mi aiuta sempre a chiedere un contributo a un collega - anche se alla fine non aiutano, di solito mi aiuta a spiegarlo almeno ad alta voce e far girare le ruote.

Stavo solo scrivendo sulle convenzioni di denominazione il mese scorso: http://caseysoftware.com/blog/useful-naming-conventions

L'essenza di esso:

verbAdjectiveNounStructure - con struttura e aggettivo come parti opzionali

Per i verbi , mi attengo ai verbi di azione: salva, elimina, notifica, aggiorna o genera. Di tanto in tanto uso "process" ma solo per fare riferimento in particolare a code o backlog di lavoro.

Per i nomi , uso la classe o l'oggetto con cui interagisco. In web2project, si tratta spesso di attività o progetti. Se Javascript interagisce con la pagina, potrebbe trattarsi di corpo o tabella. Il punto è che il codice descrive chiaramente l'oggetto con cui interagisce.

La struttura è opzionale perché è unica per la situazione. Una schermata di elenco potrebbe richiedere un elenco o un array. Una delle funzioni principali utilizzate nell'elenco progetti per web2project è semplicemente getProjectList. Non modifica i dati sottostanti, solo la rappresentazione dei dati.

Gli aggettivi sono qualcos'altro del tutto. Sono usati come modificatori del nome. Qualcosa di semplice come getOpenProjects potrebbe essere facilmente implementato con un getProjects e un parametro switch, ma ciò tende a generare metodi che richiedono un po 'di comprensione dei dati e / o struttura dell'oggetto sottostanti ... non necessariamente qualcosa che si desidera incoraggiare. Avendo funzioni più esplicite e specifiche, puoi avvolgere e nascondere completamente l'implementazione dal codice che la utilizza. Non è uno dei punti di OO?

Più che nominare una classe, creare una struttura di pacchetto appropriata può essere una sfida difficile ma gratificante. Devi considerare di separare le preoccupazioni dei tuoi moduli e il modo in cui si collegano alla visione dell'applicazione.

Considera ora il layout della tua app:

• App
  • VendorDocRequester (leggi dal servizio web e fornisci i dati)
  • VendorDocViewer (utilizzare il richiedente per fornire i documenti del fornitore)

Mi azzarderei a indovinare che c'è molto da fare in alcune classi. Se dovessi trasformare questo in un approccio più MVC-ified e consentire alle piccole classi di gestire i doveri individuali, potresti finire con qualcosa del tipo:

• App
  • VendorDocs
    • Modello
      • Documento (oggetto semplice che contiene dati)
      • WebServiceConsumer (trattare con grintoso servizio web)
    • controllore
      • DatabaseAdapter (gestire la persistenza usando ORM o altri metodi)
      • WebServiceAdapter (utilizza Consumer per prendere un documento e incollarlo nel database)
    • Visualizza
      • HelpViewer (utilizzare DBAdapter per sputare la documentazione)

Quindi i nomi delle classi si basano sullo spazio dei nomi per fornire un contesto completo. Le classi stesse possono essere intrinsecamente correlate all'applicazione senza che sia necessario dirlo esplicitamente. Di conseguenza, i nomi delle classi sono più semplici e facili da definire!

Un altro suggerimento molto importante: per favore, fatevi un favore e prendete una copia di Head First Design Patterns. È un libro fantastico e di facile lettura che ti aiuterà a organizzare la tua applicazione e a scrivere un codice migliore. Apprezzare i modelli di progettazione ti aiuterà a capire che molti dei problemi che hai incontrato sono già stati risolti e sarai in grado di incorporare le soluzioni nel tuo codice.

Leo Brodie, nel suo libro "Thinking Forth", scrisse che il compito più difficile per un programmatore era nominare bene le cose, e dichiarò che lo strumento di programmazione più importante è un thesaurus.

Prova a utilizzare il thesaurus su http://thesaurus.reference.com/ .

Oltre a ciò, non usare MAI la Notazione ungherese, evitare abbreviazioni ed essere coerenti.

Auguri.

In breve:
sono d'accordo sul fatto che i nomi di qualità siano importanti, ma non credo che devi trovarli prima di implementarli a tutti i costi.

Ovviamente è meglio avere un buon nome fin dall'inizio. Ma se non riesci a trovarne uno in 2 minuti, rinominare in seguito costerà meno tempo ed è la scelta giusta dal punto di vista della produttività.

Lungo:
generalmente non vale la pena pensare troppo a lungo a un nome prima di implementarlo. Se implementi la tua classe, chiamandola "Foo" o "Dsnfdkgx", durante l'implementazione vedi come dovresti chiamarla.

Soprattutto con Java + Eclipse, rinominare le cose non è affatto doloroso, poiché gestisce attentamente tutti i riferimenti in tutte le classi, ti avverte di collisioni di nomi, ecc. E fintanto che la classe non è ancora nel repository di controllo versione, non penso che ci sia qualcosa di sbagliato nel rinominarlo 5 volte.

Fondamentalmente, si tratta di come pensi al refactoring. Personalmente mi piace, anche se a volte infastidisce i miei compagni di squadra, poiché credono di non toccare mai un sistema in esecuzione . E da tutto ciò che puoi refactoring, cambiare nome è una delle cose più innocue che puoi fare.

Perché non HelpDocumentServiceClient in qualche modo, o HelpDocumentClient ... non importa che sia un fornitore, il punto è che è un client di un servizio web che si occupa dei documenti della Guida.

E sì, nominare è difficile.

C'è solo un nome ragionevole per quella classe:

HelpRequest

Non lasciare che i dettagli dell'implementazione ti distraggano dal significato.

Investi in un buon strumento di refactoring!

Mi attengo alle basi: VerbNoun (argomenti). Esempi: GetDoc (docID).

Non c'è bisogno di immaginarsi. Sarà facile capire tra un anno, sia tu che qualcun altro.

Per me non mi importa quanto tempo un metodo o un nome di classe è lungo quanto descrittivo e nella libreria corretta. Sono lontani i giorni in cui dovresti ricordare dove risiede ogni parte dell'API.

Intelisense esiste per tutte le principali lingue. Pertanto, quando utilizzo un'API di terze parti, mi piace usare la sua intelligenza per la documentazione anziché utilizzare la documentazione "effettiva".

Con questo in mente, sto bene per creare un nome di metodo come

StevesPostOnMethodNamesBeingLongOrShort

Lungo - ma che importa. Chi non usa schermi da 24 pollici in questi giorni!

Devo ammettere che nominare è un'arte. Diventa un po 'più semplice se la tua classe sta seguendo un certo "modello di desigh" (factory etc).

Questo è uno dei motivi per avere uno standard di codifica. Avere uno standard tende ad aiutare a trovare i nomi quando richiesto. Aiuta a liberare la mente da usare per altre cose più interessanti! (-:

Consiglio di leggere il capitolo pertinente del Codice completo di Steve McConnell ( link Amazon ) che contiene diverse regole per aiutare la leggibilità e persino la manutenibilità.

HTH

Saluti,

rapinare

No, il debug è la cosa più difficile per me! :-)

DocumentFetcher? È difficile da dire senza contesto.

Può aiutare ad agire come un matematico e prendere in prestito / inventare un lessico per il tuo dominio mentre procedi: accontentati di brevi parole semplici che suggeriscono il concetto senza spiegarlo ogni volta. Troppo spesso vedo le frasi lunghe origine latina che vengono trasformati in sigle, che hai bisogno di un dizionario per gli acronimi in ogni caso .

Il linguaggio che usi per descrivere il problema, è il linguaggio che dovresti usare per le variabili, i metodi, gli oggetti, le classi, ecc. Liberamente, i nomi corrispondono agli oggetti e i verbi corrispondono ai metodi. Se ti mancano le parole per descrivere il problema, ti manca anche una piena comprensione (specifica) del problema.

Se sta solo scegliendo tra un set di nomi, allora dovrebbe essere guidato dalle convenzioni che stai usando per costruire il sistema. Se sei arrivato in un nuovo punto, scoperto da convenzioni precedenti, allora vale sempre la pena spendere qualche sforzo nel tentativo di estenderli (correttamente, coerentemente) per coprire questo nuovo caso.

In caso di dubbio, dormici sopra e scegli il primo nome più ovvio, la mattina successiva :-)

Se ti svegli un giorno e ti rendi conto di aver sbagliato, allora cambialo subito.

Paolo.

A proposito: Document.fetch () è abbastanza ovvio.

Trovo di avere il maggior numero di problemi nelle variabili locali. Ad esempio, voglio creare un oggetto di tipo DocGetter. Quindi so che è un DocGetter. Perché devo dargli un altro nome? Di solito finisco per dargli un nome come dg (per DocGetter) o temp o qualcosa di altrettanto non descrittivo.

Non dimenticare che i modelli di progettazione (non solo quelli GoF) sono un buon modo per fornire un vocabolario comune e i loro nomi dovrebbero essere usati ogni volta che uno si adatta alla situazione. Ciò aiuterà anche i nuovi arrivati ​​che hanno familiarità con la nomenclatura a comprendere rapidamente l'architettura. Si suppone che questa classe a cui stai lavorando si comporti come un proxy o addirittura una facciata?

La documentazione del fornitore non dovrebbe essere l'oggetto? Voglio dire, quello è tangibile, e non solo una sorta di antropomorfizzazione di una parte del tuo programma. Quindi, potresti avere una VendorDocumentationclasse con un costruttore che recupera le informazioni. Penso che se un nome di classe contiene un verbo, spesso qualcosa è andato storto.

Ti sento decisamente. E sento il tuo dolore. Ogni nome a cui penso mi sembra solo spazzatura. Sembra tutto così generico e alla fine voglio imparare a iniettare un po 'di talento e creatività nei miei nomi, facendoli riflettere davvero ciò che descrivono.

Un suggerimento che ho è di consultare un Thesaurus. Word ne ha una buona, così come Mac OS X. Questo può davvero aiutarmi a far uscire la testa dalle nuvole e mi dà un buon punto di partenza e anche un po 'di ispirazione.

Se il nome si spiegasse a un programmatore laico, probabilmente non è necessario cambiarlo.