C'è un motivo per non modificare i valori dei parametri passati per valore?

Esistono argomenti oggettivi e sostenibili di ingegneria del software a favore o contro la modifica dei valori dei parametri per valore nel corpo di una funzione?

Uno sputo ricorrente (per lo più divertente) nel mio team è se i parametri passati per valore debbano essere modificati. Un paio di membri del team sono fermamente convinti che i parametri non dovrebbero mai essere assegnati, in modo che il valore originariamente passato alla funzione possa sempre essere interrogato. Non sono d'accordo e ritengo che i parametri non siano altro che variabili locali inizializzate dalla sintassi di chiamare il metodo; se il valore originale di un parametro per valore è importante rispetto a una variabile locale, può essere dichiarato per memorizzare esplicitamente questo valore. Non sono sicuro che nessuno di noi abbia un ottimo supporto per la nostra posizione.

Si tratta di un conflitto religioso non risolvibile o esistono buone ragioni oggettive di ingegneria del software in entrambe le direzioni?

Nota: la questione del principio rimane a prescindere dai dettagli di implementazione di quel particolare linguaggio. In JavaScript, ad esempio, dove l'elenco degli argomenti è sempre dinamico, i parametri possono essere considerati zucchero sintattico per l'inizializzazione della variabile locale argumentsdall'oggetto. Anche così, si potrebbero considerare gli identificatori dichiarati da parametri come "speciali" perché catturano ancora il passaggio di informazioni dal chiamante alla chiamata.

Non sono d'accordo e ritengo che i parametri non siano altro che variabili locali inizializzate dalla sintassi di chiamare il metodo

Adotto una terza posizione: i parametri sono proprio come le variabili locali: entrambi dovrebbero essere trattati come immutabili di default. Quindi le variabili vengono assegnate una volta e quindi lette solo da, non modificate. Nel caso dei loop, for each (x in ...)la variabile è immutabile nel contesto di ogni iterazione. Le ragioni sono:

1. rende il codice più facile da "eseguire nella mia testa",
2. consente nomi più descrittivi per le variabili.

Di fronte a un metodo con un gruppo di variabili che vengono assegnate e quindi non cambiano, posso concentrarmi sulla lettura del codice, piuttosto che cercare di ricordare il valore corrente di ciascuna di quelle variabili.

Di fronte allo stesso metodo, questa volta con meno variabili, ma che cambiano valore continuamente, ora devo ricordare lo stato corrente di quelle variabili, oltre a lavorare su ciò che sta facendo il codice.

Nella mia esperienza, il primo è molto più facile per il mio povero cervello. Altre persone più intelligenti di me potrebbero non avere questo problema, ma mi aiuta.

Per quanto riguarda l'altro punto:

double Foo(double r)
{
    r = r * r;
    r = Math.Pi * r;
    return r;
}

contro

double Foo(int r)
{
    var rSquared = r * r;
    var area = Math.Pi * rSquared;
    return area;
} 

Esempi contrastanti, ma a mio avviso è molto più chiaro ciò che sta accadendo nel secondo esempio a causa dei nomi delle variabili: trasmettono al lettore molte più informazioni di quante ne rfacciano quelle masse nel primo esempio.

Si tratta di un conflitto religioso non risolvibile o esistono buone ragioni oggettive di ingegneria del software in entrambe le direzioni?

Questa è una cosa che mi piace molto del C ++ (ben scritto): puoi vedere cosa aspettarti. const string& x1è un riferimento costante, string x2è una copia ed const string x3è una copia costante. Io so cosa succederà nella funzione. x2 sarà cambiato, perché se non lo fosse, non ci sarebbe motivo di renderlo non const.

Quindi, se hai una lingua che lo consente , dichiara cosa stai per fare con i parametri. Questa dovrebbe essere la scelta migliore per tutti i soggetti coinvolti.

Se la tua lingua non lo consente, temo che non ci sia una soluzione di proiettile d'argento. Entrambi sono possibili. L'unica linea guida è il principio della minima sorpresa. Adotta un approccio e seguilo in tutta la tua base di codice, non mescolarlo.

Sì, è un "conflitto religioso", tranne per il fatto che Dio non legge i programmi (per quanto ne so), quindi è ridotto a un conflitto di leggibilità che diventa una questione di giudizio personale. E certamente l'ho fatto, e l'ho visto fatto, in entrambi i modi. Per esempio,

void propagate (oggetto OBJECT *, double t0, double dt) {
  doppio t = t0; / * copia locale di t0 per evitare di modificarne il valore * /
  while (qualunque cosa) {
    timestep_the_object (...);
    t + = dt; }
  ritorno; }

Quindi qui, proprio a causa del nome dell'argomento t0 , probabilmente sceglierei di non cambiarne il valore. Ma supponiamo invece che abbiamo semplicemente cambiato il nome dell'argomento in tNow , o qualcosa del genere. Quindi mi sarei molto più che probabilmente dimenticato di una copia locale e avrei semplicemente scritto tNow + = dt; per quest'ultima affermazione.

Al contrario, supponiamo di sapere che il client per cui è stato scritto il programma sta per assumere alcuni nuovi programmatori con pochissima esperienza, che leggeranno e lavorerebbero su quel codice. Quindi probabilmente mi preoccuperei di confonderli con il pass-by-value contro-reference, mentre le loro menti sono impegnate al 100% nel tentativo di digerire tutta la logica aziendale. Quindi, in questo caso, dichiarerei sempre una copia locale di qualsiasi argomento che verrà modificato, indipendentemente dal fatto che sia più o meno leggibile per me.

Le risposte a questo tipo di domande di stile emergono con l'esperienza e raramente hanno una risposta religiosa canonica. Chiunque pensi che ci sia una sola risposta (e che lo sappia :) probabilmente ha bisogno di qualche altra esperienza.