È una cattiva pratica riutilizzare i parametri del metodo?

Question

È una cattiva pratica riutilizzare i parametri del metodo?

#1 da (10 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (-1 voti)

12

Ci sono momenti in cui dovrò modificare un valore passato in un metodo all'interno del metodo stesso. Un esempio potrebbe sanificare una stringa come questo metodo qui:

void SanitizeName(string Name)
{
    Name = Name.ToUpper();

    //now do something here with name
}

Questo è puramente innocuo poiché l'argomento Name non viene passato per riferimento. Tuttavia, se, per qualche ragione, uno sviluppatore in futuro decide di far passare tutti i valori con ref, qualsiasi sanitizzazione della stringa influenzerà il valore al di fuori del metodo che potrebbe avere risultati dannosi.

Pertanto, invece di riassegnare l'argomento stesso, creo sempre una copia locale in questo modo:

void SanitizeName(string Name)
{
    var SanitizedName = Name.ToUpper();

    //now do something here with name
}

Questo assicura che cambiando il valore in cui il valore è passato non inciderà mai su ciò che accade al di fuori del metodo, ma mi chiedo se sono eccessivamente paranoico a riguardo.

design programming-practices

posta oscilatingcretin 22.06.2016 - 13:15

fonte

4 risposte

Leggi altre domande sui tag design programming-practices

Digitare il sistema per le prestazioni Ci dovrebbe essere un indice di "igiene dei dati" per il software - per indicare quanto è pulito il programma? non lasciare file temporanei, ecc

score 10 · Answer 1

Penso che dipenda dalle convenzioni di codifica nel tuo progetto.

Personalmente ho lasciato che eclipse aggiungesse automaticamente la parola chiave final a ogni variabile e parametro. In questo modo puoi vedere a prima vista se un parametro viene riutilizzato.

Nel progetto sul mio lavoro non è consigliabile riutilizzare i parametri, ma se si desidera semplicemente chiamare per es. .trim() o imposta un valore predefinito in un caso null , riutilizziamo il parametro la maggior parte delle volte, perché l'introduzione di una nuova variabile è in questi casi meno leggibile rispetto al riutilizzo del parametro.

Non dovresti davvero riutilizzare un parametro per memorizzare un contenuto molto diverso perché il nome non farebbe più riferimento al suo contenuto. Ma questo è vero per ogni riassegnazione di una variabile e non limitata ai parametri.

Quindi unisciti al tuo team e formula convenzioni di codifica che trattano questo argomento.

score 0 · Answer 2

Se si utilizza un analizzatore di codici statici per motivi di sicurezza, potrebbe confondersi e pensare di non aver convalidato o disinfettato la variabile dei parametri di input prima dell'uso. Se si utilizza Name in una query SQL, ad esempio, potrebbe richiedere una vulnerabilità di SQL injection, il che potrebbe costare tempo a spiegazioni. Non va bene. D'altra parte, l'utilizzo di una variabile con un nome preciso per l'input igienizzato, senza sanificare effettivamente l'input, è un modo rapido per tranquillizzare gli analizzatori di codice naïve (individuazione di vulnerabilità falsamente negativa).

score 0 · Answer 3

La risposta a questo dipende al 100% da chi leggerà il tuo codice. Quali stili trovano più utili?

Ho trovato che il caso più generale è che si evita di riassegnare i valori agli argomenti della funzione perché troppi sviluppatori hanno modelli mentali su come funziona la funzione di chiamata che presuppone che non si faccia mai questo. Questo problema può essere esacerbato dai debugger che stampano i valori degli argomenti con cui si chiama ciascuna funzione. Questa informazione tecnicamente non è corretta se modifichi gli argomenti e ciò può portare a strane frustrazioni.

Detto questo, i modelli mentali cambiano. Nel tuo particolare ambiente di sviluppo, potrebbe essere desiderabile che name sia "la migliore rappresentazione del nome in questo momento." Potrebbe essere preferibile collegare in maniera più esplicita le variabili su cui stai lavorando ai loro argomenti, anche se hai apportato alcune modifiche ai loro valori lungo la strada. Potrebbero persino esserci vantaggi sostanziali di runtime per riutilizzare alcune variabili particolari piuttosto che creare oggetti più voluminosi. Dopotutto, quando lavori con stringhe da 4 GB, è bello ridurre al minimo il numero di copie extra che devi fare!

score -1 · Answer 4

Ho un problema completamente diverso con il tuo esempio di codice:

Il nome del tuo metodo è SanitizeName . In questo caso, mi aspetto che disinfetti un nome ; perché è così, quello che dici al lettore della tua funzione.

La cosa solo , che devi fare , disinfettare un determinato nome . Senza leggere il tuo codice, mi aspetto quanto segue:

string SanitizeName(string Name)
{
    //somehow sanitize the name
    return Result;
}

Ma sottintendi che il tuo metodo fa un po 'più di sanitiz solo . Questo è un odore di codice e dovrebbe essere evitato.

La tua domanda non riguarda: È una cattiva pratica riutilizzare i parametri del metodo? È più: sono gli effetti collaterali e le cattive pratiche comportamentali inesperte?

La risposta è chiaramente: yes!

This is purely harmless since the Name argument is not being passed in by reference. However, if, for some reason, a developer in the future decides to have all values passed in by ref, any sanitizing of the string will affect the value outside the method which could have detrimental results

Inganni il tuo lettore non restituendo nulla. Il tuo nome del metodo indica chiaramente che stai facendo qualcosa su Name . Quindi, dove dovrebbe andare il risultato? Con la tua firma di funzione void legge Io uso Name ma non faccio alcun danno all'id, né ti dico del risultato (esplicitamente). Forse c'è un'eccezione lanciata, forse no; ma Name non è alterato . Questo è l'opposto semantico del nome del tuo metodo.

Il problema è meno il riutilizzo di effetti collaterali . Per evitare effetti collaterali non riutilizzare una variabile. Se non hai effetti collaterali non ci sono problemi.