Le funzioni 'matematiche' dovrebbero seguire la notazione matematica?

Dipende da chi lo sta leggendo. Se puoi garantire che per tutta l'eternità, anche il prossimo programmatore che legge il tuo codice abbia familiarità con la termodinamica, allora sì, vai alla versione troncata.

Il mio stile personale è usare 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ì, 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 pensare a 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, è commenti, puoi espanderci quanto necessario), ma usa nomi di variabili descrittivi in modo che chiunque legga l'unico codice sia ancora in grado di comprenderlo facilmente, soprattutto con funzioni più ampie. Un altro motivo per cui utilizzerei le parole reali come nomi di variabili è che l'interfaccia è molto più chiara se è necessario copiare la dichiarazione della funzione in un file di intestazione.

IMHO è sempre meglio usare la notazione stabilita del dominio del problema su cui stai lavorando se la funzione è molto specifica del dominio. Qualcuno che non capisce il dominio del problema non ha alcuna possibilità di mantenere il tuo codice in ogni caso, e per qualcuno che ha familiarità con il dominio, i nomi lunghi saranno solo rumore, così come una maggiore digitazione per te.

OTHO, dirò che vorrei che le notazioni matematiche convenzionali fossero più verbose e descrittive a volte, ma a prescindere penso che il codice matematico dovrebbe attenersi alla convenzione matematica.

Modifica: questa risposta si applica solo se esiste una convenzione molto strong 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.

Pura opinione, ma usa sempre le parole sopra i simboli a lettera singola. Se usi le parole, tutti capiranno; se si usano i simboli, sono garantiti solo gli esperti di materia. Anche allora, alcune persone usano simboli diversi per le stesse quantità fisiche. Non hai nulla da perdere usando i nomi più lunghi.

La tua preoccupazione dovrebbe essere la chiarezza e la correttezza (il codice errato ma chiaro è facilmente correggibile) quindi la tua funzione dovrebbe essere scritta per la manutenibilità da parte di un programmatore generico, per quanto possibile. I commenti dell'intestazione della funzione dovrebbero spiegare la formula e il suo utilizzo e descrivere i parametri di ingresso / uscita. Da quel momento in poi, il lay-out del corpo della funzione non dovrebbe importare troppo fintanto che è coerente con i commenti dell'intestazione.

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

• In altri linguaggi che supportano l'analisi dimensionale, questo può essere implementato per es. in C ++ con i modelli, la libreria Boost Units utilizza questo approccio credo.

Dipende da quanto "lontano" dal livello aziendale è il codice ... Il furthur di nuovo nel codice è, più è mirato verso la funzione matematica astratta è implementare, più proverei ad emulare la notazione matehmatica e le convenzioni di denominazione generalmente accettate. Più vicino al front end o al livello aziendale, più mi conformerei alle convenzioni stabilite nel dominio del problema.

Mi piace pensare in questo modo - I matematici si sbagliavano con variabili corte e fisici seguivano l'esempio. Perché ripetere il loro errore? Ora sappiamo che i nomi più lunghi sono più descrittivi e producono meno confusione, quindi attenetevi al miglioramento. Su una nota più leggera, a volte cerco di introdurre le variabili più lunghe nella mia matematica, in cui tutti sono sconvolti.

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

Se torni a:

n*R*T/P;

E tu riconosci quello che sta succedendo, allora probabilmente sta bene. Tipicamente per le formule avanzate I non ricorda quale sia stata ciascuna parte a meno che non la stia utilizzando attivamente. Per me:

n_moles * BOLTZMANN_CONSTANT * temperature / pressure;

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

Lancia la moneta.

Inoltre a volte spendi più tempo a pensare a come denominare una variabile di quanto spendi per la stessa codifica?