Come posso espandere il mio vocabolario per migliorare i nomi delle variabili? [chiuso]

Come semplice regola empirica che consente una facile comprensione di ciò che è qualcosa e di ciò che farà, fondamentalmente vado con il seguente:

For a class:

Utilizza un nome che descrive di cosa si tratta. Per esempio. Veicolo, persona, edificio, account.

For a method:

Utilizza una combinazione nome-verbo . Per esempio. FixBicycle, GetPayment, CheckTicket, ReadFile. Plurali utilizzati quando il parametro consente il passaggio di multipli.

For a variable:

Utilizza un nome che descrive cosa contiene: Per esempio. Teiera, contatore, citazione, rettangolo. Plurali utilizzati quando si tratta di un array o di un elenco, ecc.

Use namespaces:

Questo aiuta a chiarire il contesto degli oggetti contenuti all'interno.

Così, mentre si può avere molti metodi 'makePayment' nella vostra applicazione, si potrebbe essere in MyApp.Customer.MakePayment, un altro potrebbe essere MyApp.Bank.MakePayment, e anche MyApp.Supplier.MakePayment.

Se hai difficoltà a pensare ai nomi perché potrebbero essere da tre a sei parole per descrivere ciò che stai facendo, ci può essere una delle tre cose sbagliate:

1. Una classe è troppo specifica, ad esempio CustomerThatBuysMoreOnWeekends

2. Un metodo sta eseguendo troppe cose da solo: prova a scomporlo nelle sue funzioni componente e nominalo come appropriato. Non nominare il metodo con tutte le cose che farà (come ad esempio PourTeaIfPotIsNotEmpty), chiamarlo con l'azione su un dato oggetto, ad esempio PourTea

3. Una variabile troppo specifica, ossia CustomersFilteredByCountry: basta utilizzare i clienti (che sono stati filtrati)

I suspect there is a particular realm of words that are sufficiently descriptive, yet common enough that any reader can follow the flow of code.

Questo dominio è il dominio per il quale stai programmando.

Di fronte a sfide di denominazione specifiche, ho trovato un thesaurus (online o cartaceo) molto utile.

Per quanto riguarda la costruzione della competenza:

Leggi molti libri di programmazione ( alta qualità ). Gli autori di questi libri avranno messo un po 'di pensiero nella denominazione di variabili e funzioni appositamente per rendere il codice il più chiaro possibile.

Ancora più importante, gli autori avranno generalmente anni di esperienza con le convenzioni comuni alla lingua o alla tecnologia in questione e tenderanno ad usare una buona denominazione idiomatica.

Naturalmente, variabili come foo e bar sono molto comuni (e per una buona ragione!) quando spiegano la sintassi per separare i nomi forniti dallo sviluppatore dalle parole chiave della lingua. Ma la maggior parte dei libri coprirà alcune cose più carnose alla fine e avrà esempi realistici.

Inoltre, leggi in particolare libri come codice completo , The Pragmatic Programmer , e altri libri di questo tipo che affrontano specificamente questi problemi di programmazione.

Anche leggere un sacco di codice sorgente di alta qualità per vedere buoni esempi è un'ottima idea, ma ora il tuo compito è ancora più difficile: trovare il codice sorgente di alta qualità !

Non posso fare a meno di aggiungere: potresti anche essere sorpreso di quanto sia grande il vocabolario per descrivere le cose che trovi nella narrativa - specialmente la fantascienza.

Dici che non vuoi solo "leggere un sacco di libri", ma questa è la mia risposta comunque. Non sarà più facile di così. Qualsiasi altro metodo può essere ugualmente efficace, ma non sarà più efficiente o semplice.

Modifica

Dopo aver riflettuto ancora su questo, dovrei anche aggiungere che questa è una di quelle abilità che ottieni facendo più di che studiano . La buona nomenclatura fa parte della pratica di programmazione stessa.

Pensare davvero duramente alla tua denominazione mentre stai facendo è costruire quell'abilità. Ecco alcune cose che personalmente cerco di concentrarmi sulla denominazione:

• Qual è il nome più breve per questa cosa?
• Il namespacing mi consente di avere nomi locali migliori?
• Questo si adatta al dominio del problema stesso o ad alcuni aspetti tecnici del codice? (Preferisci il dominio del problema per la denominazione, se puoi.)
• Sono ridondante? ( encode_function() vs encode() )
• Questo nome avrà senso per me tra un anno? (Questa domanda è difficile .)
• Questo copre il caso generale? ( red_border vs border )
• Questo troppo generale? ( stuff vs machine_state )
• Se stavo descrivendo questo ad un amico, è questa la parola che userei? In caso contrario, perché no?

L'elenco continua.

Ci vogliono anni e anni per essere veramente bravo a nominare. Ti vergognerai al codice di 5 anni. Poi, cinque anni dopo questo , ti verrai di nuovo in imbarazzo. Ripetere.

Inoltre, non abbiate paura di rinominare in seguito. Molto spesso, il nome corretto "evidentemente ovvio" di una cosa non diventa evidentemente evidente fino a quando non ci si convive per un po '!

Ciò che funziona per me quando si verifica un problema nella denominazione di un identificatore:

• Descrivi lo scopo previsto dell'identificatore in più parole o anche più frasi. Questo è importante per me per comprendere appieno il suo scopo. Potrebbe essere imbarazzante perché ti costringe a pensare. È necessario però.
• Riduci sostanzialmente questa descrizione alla sua essenza, controllando che rimanga ragionevolmente descrittiva e non ambigua.
• Per rimuovere ambiguità o mancanza di chiarezza, rinominare gli identificatori nel codice se interferiscono. (Questo passaggio può richiamare un'applicazione ricorsiva dell'intera sequenza.)
• Se necessario, lascia la descrizione più lunga come commento nel luogo di definizione.

Questo processo può farti ripensare la struttura e lo scopo di una funzione o di una classe che stai nominando, e finire come un refactoring in un modo più pulito. Questo di solito è una buona cosa se il tuo codice non è un veloce script usa e getta.

Qualche tempo fa, ho scritto un tema (per un blog che non si è mai verificato) in cui ho proposto tre regole di denominazione, in ordine di precedenza: manterale uniche , mantienili connotativi e mantienili corti . Queste regole erano focalizzate più sulla mappatura del nome che sul problema del vocabolario ricco, ma penso che si applichino ancora qui.

Unico significa che non usi la stessa variabile per indicare due cose diverse. Sembra facile, ma è sottile. Per prima cosa, significa evitare di utilizzare la stessa variabile per più scopi all'interno della stessa subroutine. Ho visto codice che riutilizza una variabile stringa in due diversi cicli di aggregazione nello stesso blocco, come se il programmatore stesse cercando di salvare quei preziosi extra byte. In un linguaggio a 4-G. Eviterei di riutilizzare un nome anche nello stesso file, principalmente per evitare potenziali bug.

Connotativo significa ciò che stai ricevendo nella domanda: il nome dovrebbe ricordare al lettore il referente. Può pagare per essere precisi qui; se una variabile denota un flusso di input di file di proprietà, preferisco propStream su propFile e propInStream su quello.

Breve è auto-esplicativo. Mentre i moderni IDE riducono il lavoro di digitare nomi a lungo variabile, non fanno nulla per la fatica di leggerli. I nomi brevi sono meno importanti, tuttavia, l'IMO e l'unicità e la significatività dovrebbero avere la precedenza. Ma nota che preferirei propInStream a propertyInStream . prop è (presumibilmente) abbastanza chiaro dal contesto.

Ritengo che un thesaurus abbia un valore limitato per la denominazione. Se ne usassi uno, sarebbe per ricordarmi di altri termini comuni per quello che sto cercando di nominare. Nel frattempo, cerco di essere generalmente ben letto, in modo da sapere cosa è di uso comune. Per esempio, non mi aspetto molto il riferimento a un elenco collegato meno la testa come il "torace".

Proprio come ci sono "lingue specifiche del dominio", ci sono anche "vocabolari specifici del dominio", ad esempio, la legge, la medicina, l'economia, ecc., tutti hanno i loro vocabolari. Piuttosto che "espandere il tuo vocabolario", di per sé, vuoi espandere la tua conoscenza del dominio del problema in cui stai lavorando.

Tutta la programmazione coinvolge alcune variabili specifiche del dominio dell'informatica, ad esempio indice, loop, elenco, array, ecc. E, per essere più facilmente leggibili, tali variabili specifiche di programmazione o di manutenzione devono essere denominate secondo le convenzioni di quel dominio . E tu presumibilmente lo sai già.

Ma qualsiasi programmazione non banale coinvolge rapidamente variabili, elementi di dati, ecc. specifici per il dominio del problema. E poi la tua denominazione delle variabili più facilmente leggibile dipenderà dalla nomenclatura, dalle convenzioni, ecc. Di quel dominio. Oltre alla programmazione della conoscenza, hai sempre bisogno di una buona comprensione del business (o di qualsiasi tipo di professione) tu ». ri programmando per. Una buona nomenclatura per le variabili relative al tuo business sarebbe solo una ragione in più.

Mi piace usare uno strumento di traduzione come link . Non sono un madrelingua inglese (anche se abbastanza fluente).

Questo non aiuta solo a trovare una traduzione inglese adeguata, ma spesso la uso avanti e indietro per trovare parole simili, ma diverse fino a quando non ho trovato "quella".