Come nominare una variabile quando la parola è sia un sostantivo che un verbo

48

Ho riscontrato un problema ad angolo con la guida generale di:

sostantivi per variabili
verbi per funzioni

Nello specifico, ho un caso in cui la parola è ambigua: può essere un verbo o un sostantivo. E in alcuni casi quando stiamo discutere l'applicazione, verrà utilizzato entrambi i modi nella stessa frase.

Il mio intento è quello di assicurarmi che il programma rimanga leggibile sia per i futuri sviluppatori che per me quando tornerò alle sezioni del codice mesi dopo.

Uno degli esempi è con a battery. A batteryha una chargee puoi anche charge()una batteria.

Penso che avere entrambi Battery.Chargee Battery.Charge(value)sarà fonte di confusione per i futuri sviluppatori.

La mia attuale soluzione è semplicemente scegliere una parola diversa per uno o entrambi i casi (la variabile e la funzione). Il mio problema con questo approccio è la Batteryvariabile e la funzione di oggetto per chargenon allinearsi con discussioni progettuali che coinvolgono il Battery.

La mia domanda è se esiste un altro / modo migliore per gestire questo conflitto nella convenzione di denominazione?

Qualche lettura aggiuntiva sull'argomento. Nessuno ha veramente affrontato il particolare della mia domanda.

naming variables

— Comunità
fonte

3

rendere la funzione di ricarica addCharge facile e chiara

— maniaco del cricchetto

2

Potresti prefissare la variabile del sostantivo con "Current-"? Quindi "CurrentCharge" vs "Charge ()"?

— Brian Snow,

6

o solo ChargeLevel per ottenere la carica corrente

— maniaco del cricchetto

5

Fai una parola. WordNet non pensa che enqueuesia una parola, ma è un verbo in Java. Che ne dici doCharge? Il test di simmetria fallirà comunque perché gli altri tuoi metodi non avranno questo prefisso

— Variabile miserabile

5

"Current" = now o "current" = flusso di carica. L'unica vera soluzione è sostituire l'inglese con una lingua più sensata!

— DarenW,

38

In situazioni simili provo a trovare sinonimi. In questo caso userei "ricarica" per il verbo. Il "ri" è leggermente ridondante, ma il significato è chiaro. L'uso della semplice "carica" per la carica rimanente nella batteria è ambiguo perché non specifica alcuna unità fisica. Preferirei "availableAmpHours", "hoursUntilRecharge" o qualcosa di simile. Le unità dipenderanno da ciò che è conveniente per l'applicazione.

La mia preferenza personale è usare i verbi solo per le funzioni che cambiano stato. Uso nomi per funzioni non mutanti. Suppongo che dipenda dal tuo punto di vista. A livello di macchina, le funzioni non mutanti fanno qualcosa, ma a livello di modello non lo fanno.

— Kevin Cline
fonte

2

Ottimo punto sulle unità. Le unità vengono esplicitamente lasciate in questo caso perché possono cambiare a seconda dell'analisi che stiamo eseguendo. Cioè, stiamo usando scale temporali diverse e la batteria regola le sue operazioni in termini di scala dell'analisi.

1

Preferisco i verbi per funzioni costose e non mutanti. Ad esempio, funzioni che eseguono una query su un database.

— Brian

20

Basta lanciarlo là fuori, ma forse la soluzione per questa istanza di ambiguità di denominazione è quella di rimuovere completamente quella funzionalità dalla batteria. Non ho mai visto una batteria a carica automatica e avrebbe più senso per me avere una classe BatteryCharger. Ciò contribuirebbe a mantenere le tue preoccupazioni più disaccoppiate e rendere l'azione più esplicita.

battery.Charge(50) vs batteryCharger.Charge(battery, 50)

Per me, il secondo modulo è molto più comprensibile e mantiene tutto il tuo codice "In carica" in un posto anziché spargerlo in tutte le classi di batteria.

— mortalapeman
fonte

6

Non è un cattivo pensiero, ma in questo caso Batteryè un'astrazione per la batteria + il sistema di ricarica. La nostra app non richiede la suddivisione dei due aspetti in oggetti separati, quindi sono raggruppati in uno (aka Battery) per comodità. In definitiva, la fisica di una batteria ricaricabile impone che abbia una sorta di funzione per accettare una carica.

In tal caso, sostengo che la risposta di kevin cline è ciò che stai cercando. Per chiarezza, utilizzerei Ricarica e Scarica per le funzioni mutanti e Carica per il nome della proprietà. Forse ChargePercent sarebbe anche una buona idea.

— mortalapeman il

Sei forse un programmatore Java? Questa è chiaramente una violazione di Don't Repeat Yourself. In effetti, stai ripetendo TUTTO tranne il parametro "50". Non potrei trovare un esempio peggiore di una violazione SECCA se provassi.

— scatola l'

@boxed Stai prendendo il mio esempio? Perché non sono sicuro di come affermare che sto violando DRY quando non ho implementato. Sono un grande sostenitore dei principi SOLID e non vedo come sei arrivato a questa conclusione.

— mortalapeman l'

Stai violando DRY creando una classe BatteryCharger non necessaria che in qualche modo causerà un cambio di stato nella batteria. Quindi BatteryCharger accetterà alcuni input che passerà immediatamente a Battery.

— Kevin Cline,

9

Evita i doppi significati

Hai deliberatamente selezionato una parola che ha più di un significato e che la prima decisione è il problema. Ci sono un sacco di parole che sono problematiche per i programmatori. Un altro esempio sarebbe phone. Puoi phonequalcuno o potresti averne uno phonein tasca.

Usa Getter e setter

La denominazione standard per la maggior parte degli oggetti sono i metodi getter / settings per le proprietà.

Battery.Charge            // would be a property
Battery.setCharge(value)  // would set the property
Battery.getCharge()       // would get the property

Le proprietà sono stati non nomi

Penso che ti sbagli classificando le proprietà degli oggetti come nomi e anche le variabili potrebbero essere pensate agli stati. Sono stati rilevanti per la portata locale della loro esistenza.

Potresti descrivere il valore che detengono come sostantivo, ma non sono sicuro che sia vero in tutti i casi.

Nella terminologia OOP le proprietà dell'oggetto descrivono lo stato di tale oggetto. Nel tuo caso Batteryè un oggetto ed Chargeè uno stato. Quindi sarebbe una proprietà dell'oggetto, ma questo dipende dal contesto in cui viene utilizzato.

Se devi essere in grado di Chargecaricare la batteria e sapere qual è la corrente Charge, allora hai un problema.

Utilizzo dell'ambito per applicare il contesto

Il contesto è ciò che chiarirà quale significato di una parola intendi comunicare con un metodo o una proprietà. Scope sta impostando l'accessibilità di una proprietà / metodo dall'esterno dell'oggetto.

Batter._charge            // a hidden private property
Battery.setCharge(value)  // would set the private property
Battery.getCharge()       // would get the private property
Battery.Charge()          // would perform the Charge action

I metodi sono verbi

Puoi descrivere il metodo di un oggetto come un verbo, ma la parola azione è più adatta. Nella terminologia OOP si eseguono azioni sugli oggetti usando i loro metodi. È una forma errata modificare la proprietà di un oggetto dall'esterno dell'oggetto. Si preferisce chiamare un metodo che esegue le azioni richieste che causano il cambiamento dello stato.

La parola Chargeè un verbo, ma è anche un sostantivo. Quando viene utilizzato per chiamare il metodo di un'azione, diventa chiaro che il verbo viene utilizzato Battery.Charge(....).

Ma il contesto è molto importante. Mentre la parola Charge()è un verbo non è significativa come startCharging().

Metodi validi per Batterypotrebbero includere Charging, Discharging, setCharge, getCharge, hasCharge, Dischargee Charged.

I semplici metodi con una sola parola spesso non dichiarano esplicitamente le loro azioni in modo chiaro, ma ci sono alcuni casi come opene in closecui è richiesta poca spiegazione.

Quindi non c'è davvero una risposta corretta su come nominare questi tipi di proprietà / metodi. Solo che è necessario utilizzare saggiamente le tecniche di cui sopra per garantire che non vi sia confusione.

— Reactgular
fonte

2

Per la cronaca, il cliente è colui che sta usando l'ambigua terminologia. Non ho creato quel casino. :-) Ho sollevato la domanda dal momento che pensavo di non essere l'unica persona che entrava in una situazione del genere. Hai alcuni punti validi nella tua risposta. In questo caso particolare, non stiamo lavorando alla granularità del tempo StartCharge()e EndCharge()ciò implicherebbe. In effetti, tale terminologia aggiungerebbe notevoli spese generali per la gestione del sistema di batterie. Ad ogni intervallo può Charge()o Discharge().

1

La lotta principale consiste nel mantenere sincroniche le semantiche di programmazione interna con la terminologia utilizzata dal client. Chargesembra essere la parola ambigua più facilmente compresa per questo dominio. Ce ne sono molti altri.

6

Preparali con i verbi che li renderanno un verbo o un sostantivo.

Battery.doCharge()

Battery.getCharge()

— Jürgen Paul
fonte

4

Per il caso verbo, penso che Chargesia OK. Per il caso del nome, getCurrentChargeLevelfunzionerebbe per te?

— FrustratedWithFormsDesigner
fonte

Non ne sono sicuro. Dato che stiamo usando C #, possiamo dichiarare il get e impostarlo sulla Proprietà invece di aver bisogno di funzioni separate. Indipendentemente da ciò, sono preoccupato per la manutenzione e come sarà una volta che avrò dimenticato quello che ho scritto. Non getCurrentChargeLevel()sarebbe comunque necessario fare riferimento a una variabile interna di Battery, e quale sarebbe il nome di quella variabile?

la carica è una tensione o una percentuale?

— mhoran_psprep,

1

@ GlenH7: Ah, capisco. Non hai specificato C # e il mio cervello è in modalità Java. Beh, in entrambi i casi, penso che per il nome che rappresenta la quantità di carica attualmente nella batteria, qualcosa sulla falsariga Battery.currentChargeLevelpotrebbe funzionare. Potresti provare a usare Battery.coloumbso Battery.ampereHoursma potrebbe non essere così ovvio ...

— FrustratedWithFormsDesigner

1

@mhoran_psprep - nessuno dei due. ;-) Chargeè Energyquale è Power(Volt * Amp == Watts) moltiplicato per il tempo. Quindi, in questo caso, l'addebito è un numero. C'è anche uno stato di carica che sembra essere una percentuale.

@FrustratedWithFormsDesigner - sì, ho lasciato fuori C # poiché pensavo che il caso d'angolo più ampio fosse applicabile indipendentemente dalla lingua. Watt*timesicuramente non si allineerebbe con le conversazioni di design, ma lo ChargeLevelfarebbe.

0

Nella maggior parte dei casi, aggiungere un verbo di aiuto, un avverbio o un aggettivo è abbastanza buono per distinguerli e può effettivamente aiutare con la comprensione. Con il tuo caso di Charge and Charge () su una batteria che lo rende DeltaCharge () potrebbe mostrare che è una funzione in grado di gestire la carica o la scarica.

Delta (nei casi in cui c'è un cambiamento ma ambiguo) è un modificatore che uso e raccomando sempre agli altri per passare il cambiamento di stato (anche se il verbo è semi-ovvio).

— Jeff Langemeier
fonte

0

Notazione ungherese in soccorso. Puoi avere intChargee fcnCharge(value), evitando così la confusione e non aggiungere un nome lungo pazzo quando tre lettere funzioneranno bene.

Oppure potresti semplicemente usare lo stesso nome e lasciare che l'IDE lo gestisca. La creazione di un nome più lungo o diverso può comunque essere altrettanto confusa nel lungo periodo.

— Ryathal
fonte

+1 per la prospettiva unica sulla risposta. Purtroppo, la notazione ungherese è esplicitamente dettagliata secondo le nostre linee guida sullo stile del codice. Ciò non cambia il potenziale merito della tua risposta, solo che non posso usarla come la mia soluzione effettiva.