Asignar variable en la declaración de condición if, ¿buena práctica o no? [cerrado]

Hace un año me mudé de los lenguajes OO clásicos como Java a JavaScript. El siguiente código definitivamente no se recomienda (o incluso no es correcto) 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;
}

Básicamente, acabo de descubrir que puedo asignar una variable a un valor en una declaración de condición if e inmediatamente verificar el valor asignado como si fuera booleano.

Para una apuesta más segura, generalmente lo separo en dos líneas de código, primero lo asigno y luego verifico la variable, pero ahora que encontré esto, me pregunto si es una buena práctica o no a los ojos de los desarrolladores de JavaScript experimentados.

Yo no lo recomendaría. El problema es que parece un error común en el que intenta comparar valores, pero usa un solo en =lugar de ==o ===. Por ejemplo, cuando ve esto:

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

no sabes si eso es lo que querían hacer o si tenían la intención de escribir esto:

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

Si realmente desea hacer la tarea en su lugar, le recomendaría hacer una comparación explícita también:

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

No veo ninguna prueba de que no sea una buena práctica. Sí, puede parecer un error, pero se remedia fácilmente con comentarios juiciosos. Tomemos, por ejemplo:

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

¿Por qué debería permitirse que esa función se ejecute por segunda vez con:

alert(processorIntensiveFunction());

¿Porque la primera versión se ve mal? No puedo estar de acuerdo con esa lógica.

Lo hice muchas veces. Para omitir la advertencia de JavaScript, agrego dos parens:

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

Debes evitarlo, si realmente quieres usarlo, escribe un comentario encima diciendo lo que estás haciendo.

También puede hacer esto en Java. Y no, no es una buena práctica. :)

(Y use ===en Javascript para la igualdad de tipos. Lea el libro The Good Parts de Crockford sobre JS).

Hay un caso en el que lo haces, con while-loops.
Cuando lee archivos, normalmente lo hace así:

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

Mire el while-loop en la línea 9. Allí, se lee una nueva línea y se almacena en una variable, y luego se ejecuta el contenido del bucle. Sé que esto no es una ifdeclaración-, pero supongo que también se puede incluir un ciclo while en su pregunta.

La razón de esto es que cuando usa a FileInputStream, cada vez que llama FileInputStream.readLine(), lee la siguiente línea en el archivo, por lo que si lo hubiera llamado desde el bucle con solo fileIn.readLine() != nullsin asignar la variable, en lugar de llamar (currentLine = fileIn.readLine()) != null, y luego lo hubiera llamado desde dentro del bucle también, solo obtendría cada segunda línea.

Espero que lo entiendas y ¡buena suerte!

También puede hacer asignaciones dentro de declaraciones if en Java. Un buen ejemplo sería leer algo y escribirlo:

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

El código:

// 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 tuviera que consultar el libro de Martin Fowlers Refactorización mejorando el diseño del código existente ! Luego, hay varios casos en los que sería una buena práctica, por ejemplo. condicionales largos y complejos para usar una función o llamada a un método para afirmar su caso:

"Motivación

Una de las áreas de complejidad más comunes en un programa radica en la lógica condicional compleja. A medida que escribe código para probar condiciones y para hacer varias cosas dependiendo de varias condiciones, rápidamente termina con un método bastante largo. La longitud de un método es en sí mismo un factor que dificulta la lectura, pero las condiciones aumentan la dificultad. El problema generalmente radica en el hecho de que el código, tanto en las verificaciones de condición como en las acciones, le dice lo que sucede, pero puede ocultar fácilmente por qué sucede.

Al igual que con cualquier bloque grande de código, puede aclarar su intención descomponiéndolo y reemplazando fragmentos de código con una llamada a un método con el nombre de la intención de ese bloque de código. > Con condiciones, puede recibir un beneficio adicional al hacer esto para la parte condicional y cada una de las alternativas. De esta manera, resalta la condición y deja claramente en qué se está ramificando. También destaca el motivo de la ramificación ".

Y sí, su respuesta también es válida para implementaciones de Java. Aunque no asigna la función condicional a una variable en los ejemplos.

No es una buena práctica. Pronto te confundirás al respecto. Parece similar a un error común: mal uso de los operadores "=" y "==".

Debes dividirlo en 2 líneas de códigos. No solo ayuda a que el código sea más claro, sino que también es fácil de refactorizar en el futuro. ¿Imagina que cambia la condición IF? Puede eliminar accidentalmente la línea y su variable ya no obtendrá el valor asignado.

Consideraría esto más como un estilo C de la vieja escuela; no es una buena práctica en JavaScript, por lo que debe evitarlo.

podrías hacer algo como esto:

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

Vine aquí desde Golang, donde es común ver algo como

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

En el que errestá limitado a ese ifbloque únicamente. Como tal, esto es lo que estoy haciendo en es6, que parece bastante feo, pero no hace que mis estrictas reglas de eslint se quejen, y logra lo mismo.

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

¿Las llaves extra definen un nuevo, eh, "alcance léxico"? Lo que significa que puedo usar consty errno está disponible para el bloque externo.