Attribuer une variable dans si la déclaration de condition, bonne pratique ou non? [fermé]

Il y a un an, je suis passé des langages OO classiques tels que Java à JavaScript. Le code suivant n'est certainement pas recommandé (ou même pas correct) en 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;
}

Fondamentalement, je viens de découvrir que je peux attribuer une variable à une valeur dans une instruction de condition if et vérifier immédiatement la valeur attribuée comme si elle était booléenne.

Pour un pari plus sûr, je sépare généralement cela en deux lignes de code, attribuez d'abord puis vérifiez la variable, mais maintenant que j'ai trouvé cela, je me demande simplement si c'est une bonne pratique ou non aux yeux des développeurs JavaScript expérimentés?

Je ne le recommanderais pas. Le problème est que cela ressemble à une erreur courante où vous essayez de comparer des valeurs, mais utilisez un seul =au lieu de ==ou ===. Par exemple, lorsque vous voyez ceci:

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

vous ne savez pas si c'est ce qu'ils voulaient faire, ou s'ils avaient l'intention d'écrire ceci:

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

Si vous voulez vraiment faire la tâche sur place, je vous recommande également de faire une comparaison explicite:

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

Je ne vois aucune preuve que ce n'est pas une bonne pratique. Oui, cela peut ressembler à une erreur, mais cela est facilement corrigé par des commentaires judicieux. Prenons par exemple:

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

Pourquoi cette fonction devrait-elle être autorisée à s'exécuter une deuxième fois avec:

alert(processorIntensiveFunction());

Parce que la première version a l'air mauvais? Je ne peux pas être d'accord avec cette logique.

Je l'ai fait plusieurs fois. Pour contourner l'avertissement JavaScript, j'ajoute deux parens:

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

Vous devriez l'éviter, si vous voulez vraiment l'utiliser, écrivez un commentaire dessus en disant ce que vous faites.

Vous pouvez également le faire en Java. Et non, ce n'est pas une bonne pratique. :)

(Et utilisez le ===en Javascript pour l'égalité typée. Lisez le livre The Good Parts de Crockford sur JS.)

Il y a un cas où vous le faites, avec while-loops.
Lors de la lecture de fichiers, vous faites généralement comme ceci:

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
        }
    }
}

Regardez le while-loop à la ligne 9. Là, une nouvelle ligne est lue et stockée dans une variable, puis le contenu de la boucle est exécuté. Je sais que ce n'est pas une ifdéclaration, mais je suppose qu'une boucle while peut également être incluse dans votre question.

La raison en est que lors de l'utilisation de a FileInputStream, chaque fois que vous appelez FileInputStream.readLine(), il lit la ligne suivante du fichier, donc si vous l'auriez appelé à partir de la boucle avec juste fileIn.readLine() != nullsans affecter la variable, au lieu d'appeler (currentLine = fileIn.readLine()) != null, puis l' avez appelé à partir de à l'intérieur de la boucle aussi, vous n'obtiendrez qu'une ligne sur deux.

J'espère que vous comprenez, et bonne chance!

Vous pouvez également effectuer des affectations dans les instructions if en Java. Un bon exemple serait de lire quelque chose et de l'écrire:

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

Le code:

// 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();
}

Si vous deviez vous référer au livre de Martin Fowlers Refactoring améliorant la conception du code existant ! Ensuite, il y a plusieurs cas où ce serait une bonne pratique, par exemple. conditionnelles longues et complexes pour utiliser un appel de fonction ou de méthode pour affirmer votre cas:

"Motivation

L'un des domaines de complexité les plus courants d'un programme réside dans la logique conditionnelle complexe. Lorsque vous écrivez du code pour tester les conditions et pour faire diverses choses en fonction de diverses conditions, vous vous retrouvez rapidement avec une méthode assez longue. La longueur d'une méthode est en elle-même un facteur qui la rend plus difficile à lire, mais les conditions augmentent la difficulté. Le problème réside généralement dans le fait que le code, à la fois dans les vérifications de conditions et dans les actions, vous dit ce qui se passe mais peut facilement obscurcir pourquoi cela se produit.

Comme pour tout gros bloc de code, vous pouvez rendre votre intention plus claire en la décomposant et en remplaçant des morceaux de code par un appel de méthode nommé d'après l'intention de ce bloc de code. > Avec des conditions, vous pouvez bénéficier d'un avantage supplémentaire en faisant cela pour la partie conditionnelle et chacune des alternatives. De cette façon, vous mettez en évidence la condition et faites clairement ce sur quoi vous vous branchez. Vous mettez également en évidence la raison de la ramification. "

Et oui, sa réponse est également valable pour les implémentations Java. Il n'affecte pas la fonction conditionnelle à une variable dans les exemples.

Ce n'est pas une bonne pratique. Vous serez bientôt confus à ce sujet. Cela ressemble à une erreur courante: une mauvaise utilisation des opérateurs "=" et "==".

Vous devez le diviser en 2 lignes de codes. Cela permet non seulement de rendre le code plus clair, mais également de le refactoriser à l'avenir. Imaginez que vous modifiez la condition IF? Vous pouvez accidentellement supprimer la ligne et votre variable ne reçoit plus la valeur qui lui est attribuée.

Je considérerais cela plus comme un style C à l'ancienne; ce n'est pas vraiment une bonne pratique en JavaScript, vous devriez donc l'éviter.

vous pouvez faire quelque chose comme ceci:

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

Je suis venu ici du golang, où il est courant de voir quelque chose comme

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

Dans lequel errest limité à ce ifbloc uniquement. En tant que tel, voici ce que je fais dans es6, qui semble assez moche, mais ne fait pas pleurnicher mes règles d'eslint plutôt strictes, et réalise la même chose.

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

Les accolades supplémentaires définissent une nouvelle, euh, "portée lexicale"? Ce qui signifie que je peux utiliser constet que je ne suis errpas disponible pour le bloc externe.