Sovrascrittura e restituzione del valore dell'argomento utilizzato come condizionale di un'istruzione if, all'interno della stessa istruzione if

Question

Sovrascrittura e restituzione del valore dell'argomento utilizzato come condizionale di un'istruzione if, all'interno della stessa istruzione if

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

2

Un esempio semplificato:

function logTheColor (color){
    if(color == "red"){
        color = "The color is red "
    } else if (color == "yellow") {
        color = "The color is yellow "
    } else {
        color =  "The color is blue"
    }   
    console.log(color);
}

C'è qualcosa di sbagliato nel sovrascrivere il valore della variabile all'interno di un'istruzione if, se anche quella variabile fa parte della condizione dell'istruzione if? La mia domanda non riguarda il modo in cui posso ottenere lo stesso risultato in modo "pulito", voglio solo sapere se è giusto anche se sembra una cattiva pratica.
Non vedo alcun problema in questo caso particolare perché non devo rivalutare la variabile "colore" con il contenuto originale di nuovo. Mi sto perdendo qualcosa? Ci sono casi in cui è davvero importante?

variables javascript if-statement

posta Alejandro Veltri 15.10.2014 - 00:41

fonte

4 risposte

Leggi altre domande sui tag variables javascript if-statement

Si tratta di una situazione comunemente riscontrata in C ++? C'è un modello per gestirlo? Cosa si intende per "Requisiti di sistema" e in che modo si riferisce a "Requisito funzionale"?

score 3 · Answer 1

Chi è il "proprietario" del parametro passato?

Considerare la situazione in cui il valore del colore viene modificato dalla funzione e viene passato per riferimento. Questo potrebbe non essere sempre qualcosa che puoi controllare (passa per valore o passa per riferimento).

#include <iostream>
using namespace std;

void doFoo(int& arg) {
    arg++;
}

int main(void) {
    int foo = 42;
    doFoo(foo);
    cout << foo;
    return 0;
}

link

Questo codice stampa 43. La funzione doFoo ha ottenuto l'argomento per riferimento e l'ha modificata. Questo potrebbe essere ciò che dovrebbe fare, e ci sono certamente dei momenti in cui essere consapevole di ciò. Ma, se la funzione non "possiede" l'argomento quando entra, un tale effetto collaterale può essere piuttosto brutto.

Questo concetto di proprietà è reale e ha implicazioni nei luoghi. Nell'obiettivo C pre-arco, in effetti si chiamerebbero retain e release sulle cose se si volessero "possederle". In alternativa, puoi crearne una copia (non quello che stai indirizzando) e quella copia.

Spesso, la migliore pratica è considerare che gli argomenti passati sono cose finali immutabili che non dovresti toccare. La riassegnazione dei parametri è spesso vista come una pratica discutibile - anche se la cosa impossibile cambiare. Lo specifico di se può cambiare da lingua a lingua, o anche in silenzio all'interno di un linguaggio (la differenza percepita nel passare un Object e un int in Java).

Modifica di una cosa

Mettendo da parte il parametro che si sta modificando, un codice come questo stabilisce la possibilità / probabilità di diventare non mantenibile nel tempo.

La modifica della condizione per if (o indice in un ciclo for ), in una serie di istruzioni if (sì, hai un else in là) può portare al codice in cui dipendi da un valore cambiare stato in un precedente se, che non lo fa (e ha uno stato diverso ).

Questo inizia ad entrare in esempi piuttosto inventati cercando di dimostrarlo in un breve pezzetto di codice. Spesso questo avviene con blocchi di codice più grandi dove pensi che nulla più tardi lo usi, quindi è sicuro modificarlo ... e poi qualcuno entra, guarda i compiti, guarda le cento linee di codice (troverai questo in codice si sostiene che "qualcun altro ha scritto" tutto il tempo), sfiorare dove è necessario apportare la modifica ... apportare il cambiamento e scoprire che la cosa che hai qui ora, non è la cosa che era nella parte superiore del blocco.

Il codice di esempio ... ha un odore di odore di codice che ha il profumo di Same Name Different Meaning - gli identificatori identici che verrebbero indirizzati da Split Temporary Variable . Anche questo non una variabile temporanea è problematico.

score 1 · Answer 2

Per questo particolare esempio, per questo particolare linguaggio, è tecnicamente corretto. Tuttavia, considera questa citazione di Tony Hoare:

There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it.

Il problema con il tuo esempio è che non puoi guardarlo e dire che non ci sono ovviamente bug in esso. Non scrivo codice JavaScript ogni giorno, ma ho scritto alcune app che comprendono diverse migliaia di righe di codice ciascuna. Ho dovuto scrivere ed eseguire un test per determinare che il tuo esempio non avesse bug.

Se color è stato passato per riferimento, avresti creato un bug.

Se stavi lavorando in una lingua in cui è stato creato un nuovo scope all'interno di ogni blocco condizionale, creando così una nuova variabile anche di nome color che è uscita dall'ambito immediatamente dopo essere stata assegnata, hai creato un bug.

Se una modifica futura ha bisogno di utilizzare in seguito il valore originale color , hai forzato un refactore.

Ogni volta che qualcuno legge la tua funzione in futuro, spenderà lo sforzo mentale mantenendo i due diversi colors diretti, il che rende molto più difficile capire e mantenere il codice.

Non rendere il tuo standard di codifica il minimo con cui puoi cavartela e il tuo programma funziona. Rendilo così semplice che non ci siano ovviamente bug in esso.

score 0 · Answer 3

Non dirò che è sempre sbagliato, ma in genere è una cattiva idea.

I nomi delle funzioni non dovrebbero mentire.
Il nome della funzione dice che registra il colore.
Il nome funzione non dice che cambia colore.
Il nome della funzione giace.
La funzione cambia colore come effetto collaterale.
Gli effetti collaterali nelle funzioni non sono una buona idea secondo il Codice pulito di Uncle Bob
Se lo fai in molti punti del tuo codice, il codice sarà un incubo di manutenzione.

Si prega di non codificare come se si gettasse immediatamente il codice. Codice come se il codice verrà riutilizzato in futuro, non solo da te ma da altri.

score 0 · Answer 4

Qui ricicla una variabile per non aver bisogno di dichiarare una variabile locale. Il nome della variabile originale color diventa una nozione come color_description . È cattivo stile per riciclare le variabili, in particolare per una diversa entità.

In realtà non è uno sforzo da scrivere:

var description;
if (color == "red") {
    description = "The color is red ";
} else if (color == "yellow") {
    description = "The color is yellow ";
} else {
    description = "The color is blue";
}

o

var description =
    color == "red" ? "The color is red "
    : color == "yellow" ? "The color is yellow "
    : "The color is blue";