Assegnare una variabile nella dichiarazione della condizione if, buona pratica o no? [chiuso]

Sono passato un anno fa dai classici linguaggi OO come Java a JavaScript. Il codice seguente è decisamente sconsigliato (o addirittura non corretto) in Java:

if(dayNumber = getClickedDayNumber(dayInfo))
{
    alert("day number found : " + dayNumber);
}
function getClickedDayNumber(dayInfo)
{
    dayNumber = dayInfo.indexOf("fc-day");
    if(dayNumber != -1) //substring found
    {
        //normally any calendar month consists of "40" days, so this will definitely pick up its day number.
        return parseInt(dayInfo.substring(dayNumber+6, dayNumber+8));
    }
    else return false;
}

Fondamentalmente ho appena scoperto che posso assegnare una variabile a un valore in un'istruzione if condition e controllare immediatamente il valore assegnato come se fosse booleano.

Per una scommessa più sicura, di solito lo separo in due righe di codice, prima assegno quindi controllo la variabile, ma ora che ho trovato questo, mi chiedo solo se è una buona pratica o meno agli occhi degli sviluppatori JavaScript esperti?

Non lo consiglierei. Il problema è che sembra un errore comune in cui si tenta di confrontare i valori, ma si utilizza un singolo =invece di ==o ===. Ad esempio, quando vedi questo:

if (value = someFunction()) {
    ...
}

non sai se è quello che intendevano fare, o se intendevano scrivere questo:

if (value == someFunction()) {
    ...
}

Se vuoi davvero svolgere il compito sul posto, ti consiglio di fare anche un confronto esplicito:

if ((value = someFunction()) === <whatever truthy value you are expecting>) {
    ...
}

Non vedo alcuna prova che non sia una buona pratica. Sì, può sembrare un errore, ma è facile rimediare con commenti giudiziosi. Prendiamo ad esempio:

if (x = processorIntensiveFunction()) { // declaration inside if intended
    alert(x);
}

Perché quella funzione dovrebbe essere autorizzata a essere eseguita una seconda volta con:

alert(processorIntensiveFunction());

Perché la prima versione sembra brutta? Non posso essere d'accordo con questa logica.

L'ho fatto molte volte. Per bypassare l'avviso JavaScript, aggiungo due parentesi:

if ((result = get_something())) { }

Dovresti evitarlo, se vuoi davvero usarlo, scrivi un commento sopra di esso dicendo cosa stai facendo.

Puoi farlo anche in Java. E no, non è una buona pratica. :)

(E usa ===Javascript per l'uguaglianza digitata. Leggi il libro The Good Parts di Crockford su JS.)

C'è un caso in cui lo fai, con while-loops.
Durante la lettura dei file, di solito ti piace questo:

void readFile(String pathToFile) {
    // Create a FileInputStream object
    FileInputStream fileIn = null;
    try {
        // Create the FileInputStream
        fileIn = new FileInputStream(pathToFile);
        // Create a variable to store the current line's text in
        String currentLine;
        // While the file has lines left, read the next line,
        // store it in the variable and do whatever is in the loop
        while((currentLine = in.readLine()) != null) {
            // Print out the current line in the console
            // (you can do whatever you want with the line. this is just an example)
            System.out.println(currentLine);
        }
    } catch(IOException e) {
        // Handle exception
    } finally {
        try {
            // Close the FileInputStream
            fileIn.close();
        } catch(IOException e) {
            // Handle exception
        }
    }
}

Guarda il whileciclo alla riga 9. Lì, una nuova riga viene letta e memorizzata in una variabile, quindi viene eseguito il contenuto del ciclo. So che questa non è ifun'affermazione, ma immagino che anche un ciclo while possa essere incluso nella tua domanda.

La ragione di ciò è che quando si utilizza a FileInputStream, ogni volta che si chiama FileInputStream.readLine(), legge la riga successiva nel file, quindi se l'avessi chiamata dal ciclo fileIn.readLine() != nullsenza assegnare la variabile, invece di chiamare (currentLine = fileIn.readLine()) != null, e poi la chiamassi da anche all'interno del ciclo, otterrai solo una riga su due.

Spero tu capisca e buona fortuna!

È anche possibile eseguire assegnazioni all'interno di istruzioni if ​​in Java. Un buon esempio sarebbe leggere qualcosa e scriverlo:

http://www.exampledepot.com/egs/java.io/CopyFile.html?l=new

Il codice:

// Copies src file to dst file.
// If the dst file does not exist, it is created
void copy(File src, File dst) throws IOException 
{
    InputStream in = new FileInputStream(src);
    OutputStream out = new FileOutputStream(dst);

    // Transfer bytes from in to out
    byte[] buf = new byte[1024];
    int len;
    while ((len = in.read(buf)) > 0) {
        out.write(buf, 0, len);
    }
    in.close();
    out.close();
}

Se dovessi fare riferimento al libro di Martin Fowlers Refactoring che migliora il design del codice esistente ! Poi ci sono diversi casi in cui sarebbe una buona pratica, ad es. condizionali lunghi e complessi per utilizzare una chiamata di funzione o metodo per affermare il tuo caso:

"Motivazione

Una delle aree più comuni di complessità in un programma risiede nella complessa logica condizionale. Mentre scrivi codice per testare le condizioni e per fare varie cose a seconda delle varie condizioni, ti ritroverai rapidamente con un metodo piuttosto lungo. La lunghezza di un metodo è di per sé un fattore che rende più difficile la lettura, ma le condizioni aumentano la difficoltà. Il problema di solito sta nel fatto che il codice, sia nella verifica delle condizioni che nelle azioni, ti dice cosa succede ma può facilmente oscurare il motivo per cui accade.

Come con qualsiasi blocco di codice di grandi dimensioni, è possibile rendere più chiara la propria intenzione scomponendola e sostituendo blocchi di codice con una chiamata al metodo che prende il nome dall'intenzione di quel blocco di codice. > Con le condizioni puoi ricevere ulteriori vantaggi facendo ciò per la parte condizionale e ciascuna delle alternative. In questo modo si evidenzia la condizione e si rende chiaramente> su cosa si sta ramificando. Evidenzia anche il motivo della ramificazione ".

E sì, la sua risposta è valida anche per le implementazioni Java. Non assegna la funzione condizionale a una variabile sebbene negli esempi.

Non è una buona pratica. Presto ti confonderai. Sembra simile a un errore comune: uso improprio degli operatori "=" e "==".

Dovresti suddividerlo in 2 righe di codici. Non solo aiuta a rendere il codice più chiaro, ma anche facile da refactoring in futuro. Immagina di cambiare la condizione IF? Potresti rimuovere accidentalmente la riga e la tua variabile non riceverà più il valore assegnato.

Lo considererei più uno stile C della vecchia scuola; non è davvero una buona pratica in JavaScript, quindi dovresti evitarlo.

potresti fare qualcosa del genere:

if (value = /* sic */ some_function()){
  use_value(value)
}

Sono venuto qui da Golang, dove è comune vedere qualcosa di simile

if (err := doSomething(); err != nil) {
    return nil, err
}

In cui errè limitato solo a quel ifblocco. In quanto tale, ecco cosa sto facendo in es6, che sembra piuttosto brutto, ma non fa lamentare le mie regole di eslint piuttosto rigide e ottiene lo stesso.

{
  const err = doSomething()
  if (err != null) {
    return (null, err)
  }
}

Le parentesi graffe extra definiscono un nuovo, uh, "ambito lessicale"? Il che significa che posso usare conste errnon è disponibile per il blocco esterno.