Le funzioni "matematiche" dovrebbero seguire la notazione matematica?

Suppongo che questa domanda verrà immediatamente contrassegnata come soggettiva, ma quale pensi sia meglio:

double volume(double pressure, double n_moles, double temperature) {
  return n_moles * BOLTZMANN_CONSTANT * temperature / pressure;
}

o

double volume(double P, double n, double T) {
  return n*R*T/P;
}

In altre parole, le funzioni che implementano alcune equazioni dovrebbero seguire la notazione di quella equazione o dovrebbero usare nomi più dettagliati?

Dipende da chi lo sta leggendo. Se puoi garantirlo per tutta l'eternità, il prossimo programmatore che legge il tuo codice ha anche familiarità con la termodinamica, quindi sì, scegli la versione troncata.

Il mio stile personale è quello di utilizzare tali variabili (le cui abbreviazioni sono comunemente note nel campo), ma includere la loro descrizione nei commenti.

/* P : Pressure
   V : Volume
   n : Number of moles
   R : Boltzmann constant
   T : Temperature (in K)
*/
double compute_V(double P, double n, double T) {
  return n*R*T/P;
}

Basta lanciarlo là fuori, hai un'altra opzione:

Volume ComputeVolume(Pressure p, Moles m, Temperature t) { ... }

Questo è in qualche modo simile a quello che fa F # con le unità di misura e ha il vantaggio di evitare problemi come la sostituzione involontaria di una pressione con una temperatura. È difficile capire quali argomenti dovrebbero andare quando la firma è simile (doppia, doppia, doppia)

Preferisco questo:

/* This function calculates volume using the following formula:
 *
 *     n * R * T
 * v = ---------
 *         P
 */
double volume(double pressure, double n_moles, double temperature) {
    return n_moles * BOLTZMANN_CONSTANT * temperature / pressure;
}

In altre parole, spiega il significato del codice nel commento in inglese (e in matematica; sono i commenti, puoi espanderlo quanto basta), ma usa nomi di variabili descrittivi in ​​modo che chiunque legga l'unico codice sia ancora in grado di comprendere facilmente - specialmente con funzioni più grandi. Un altro motivo per cui userei parole reali come nomi di variabili è che l'interfaccia è molto più chiara se è necessario copiare la dichiarazione di funzione in un file di intestazione.

IMHO è sempre meglio usare la notazione stabilita del dominio problematico in cui stai lavorando se la funzione è molto specifica del dominio. Qualcuno che non capisce il dominio problematico non ha alcuna possibilità di mantenere con successo il tuo codice in ogni caso, e per qualcuno che abbia familiarità con il dominio, i nomi lunghi saranno solo rumorosi, così come più digitazioni per te.

OTHO, dirò che vorrei che la notazione matematica convenzionale fosse a volte più dettagliata e descrittiva, ma indipendentemente dal fatto che penso che il codice matematico dovrebbe attenersi alla convenzione matematica.

Modifica: questa risposta si applica solo se esiste una convenzione molto forte sulla notazione quando si scrive la formula matematicamente. Se non ce n'è uno, e dovresti spiegare cosa rappresentano le variabili in un commento anche supponendo che il lettore abbia familiarità con il dominio, allora è meglio sbagliare sul lato di una convenzione più descrittiva.

Opinione pura, ma usa sempre le parole sopra i simboli di una sola lettera. Se usi le parole, tutti capiranno; se usi simboli, solo gli esperti in materia sono tenuti a seguirlo. Anche allora, alcune persone usano simboli diversi per le stesse quantità fisiche. Non hai nulla da perdere usando i nomi più lunghi.

La vostra preoccupazione dovrebbe essere la chiarezza e poi la correttezza (il codice errato ma chiaro può essere facilmente corretto), pertanto la vostra funzione dovrebbe essere scritta per la manutenibilità da un programmatore generico per quanto possibile. I commenti dell'intestazione della funzione dovrebbero spiegare la formula e il suo utilizzo e descrivere i parametri in / out. Successivamente, il modo in cui è strutturato il corpo della funzione non dovrebbe importare troppo, purché sia ​​coerente con i commenti dell'intestazione.

(So ​​che questa non è una discussione ma - la mia preferenza personale sarebbe quella di dare nomi espliciti ai variegati anche se in questo caso un one-liner potrebbe essere sufficiente in quanto è una funzione 'pura'; una chiamata con gli stessi parametri produrrebbe lo stesso risultato sempre quindi non ci dovrebbero essere complessità legate allo stato che richiedono spiegazioni)

• Per quanto riguarda gli altri linguaggi che supportano l'analisi dimensionale, questo può essere implementato ad esempio in C ++ con modelli, credo che la libreria Boost Units utilizzi questo approccio.

Dipende da quanto "lontano" dal livello aziendale è il codice ... Più lo stack nel codice è il codice, più è mirato verso la funzione matematica astratta è implementata, più tenterei di emulare il generalmente accettato convenzioni di notazione e denominazione matematiche. Più vicino al front-end o al livello aziendale, più mi adeguerei alle convenzioni stabilite nel dominio del problema.

Mi piace pensarlo in questo modo - i matematici hanno sbagliato con variabili brevi e i fisici hanno seguito l'esempio. Perché ripetere il loro errore? Ora sappiamo che i nomi più lunghi sono più descrittivi e producono meno confusione, quindi attenersi al miglioramento. Su una nota più leggera, a volte cerco di intrufolarmi variabili più lunghe nei miei calcoli, a cui tutti sono sconvolti.

Il formato corretto per un'equazione di programmazione è quello che capisci ancora dopo non averlo visto per sei mesi.

Se torni a:

n*R*T/P;

E riconosci cosa sta succedendo, quindi probabilmente va bene. In genere per le formule avanzate non ricordo quale fosse ciascuna parte a meno che non la stia usando attivamente. Per me:

n_moles * BOLTZMANN_CONSTANT * temperature / pressure;

è un formato di equazione molto migliore, in particolare perché posso facilmente capire ogni parte, anche se non so necessariamente perché l'equazione sia scritta così com'è.

Lancia la moneta.

A volte passi anche più tempo a pensare a come nominare una variabile che a spendere per la codifica stessa?