Назначить переменную в выражении условия, хорошей практике или нет?

Ответ 1

Я бы не рекомендовал его. Проблема в том, что это похоже на общую ошибку, когда вы пытаетесь сравнить значения, но используйте один = вместо == или ===. Например, когда вы видите это:

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

вы не знаете, что они хотели сделать, или если они намеревались написать это:

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

Если вы действительно хотите выполнить задание, я бы рекомендовал также выполнить явное сравнение:

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

Ответ 2

Я не вижу никаких доказательств того, что это не хорошая практика. Да, это может показаться ошибкой, но это легко исправить разумным комментарием. Возьмем, к примеру:

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

Зачем эта функция должна запускаться во второй раз с помощью:

alert(processorIntensiveFunction());

Потому что первая версия LOOKS плохой? Я не могу согласиться с этой логикой.

Ответ 3

Я делал это много раз. Чтобы обойти предупреждение JavaScript, я добавляю два параметра:

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

Вам следует избегать этого, если вы действительно хотите его использовать, напишите над ним комментарий, говорящий о том, что вы делаете.

Ответ 4

Вы можете сделать это и на Java. И нет, это не очень хорошая практика.:)

(И используйте === в Javascript для типизированного равенства. Прочитайте Крокфорда "Книга добрых частей" на JS.)

Ответ 5

Есть один случай, когда вы это делаете, while -loops.
При чтении файлов вы обычно делаете так:

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

Посмотрите на while -loop в строке 9. Там новая строка считывается и сохраняется в переменной, а затем выполняется содержимое цикла. Я знаю, что это не if -statement, но я думаю, что цикл while также может быть включен в ваш вопрос.

Причиной этого является то, что при использовании FileInputStream каждый раз, когда вы вызываете FileInputStream.readLine(), он читает следующую строку в файле, поэтому, если бы вы вызвали его из цикла только с fileIn.readLine() != null без назначения вместо вызова (currentLine = fileIn.readLine()) != null, а затем вызвала его изнутри цикла, вы получите только каждую вторую строку.

Надеюсь, вы понимаете, и удачи!

Ответ 6

Вы можете выполнять задания в операторах if в Java. Хорошим примером было бы прочитать что-то и написать его:

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

Код:

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

Ответ 7

Это не очень хорошая практика. Вы скоро смутитесь. Он похож на общую ошибку: неправильное использование операторов "=" и "==".

Вы должны разбить его на две строки кодов. Это не только помогает сделать код более четким, но и легким для рефакторинга в будущем. Представьте, что вы меняете условие IF? Вы можете случайно удалить строку, и ваша переменная больше не получит назначенное ей значение.

Ответ 8

Если бы вы обратились к книге Мартина Фаулера " Рефакторинг, улучшающий дизайн существующего кода" ! Тогда есть несколько случаев, когда это будет хорошей практикой, например. длинные сложные условия для использования вызова функции или метода для подтверждения вашего случая:

"Мотивация

Одна из наиболее распространенных областей сложности в программе заключается в сложной условной логике. Когда вы пишете код для проверки условий и выполнения различных действий в зависимости от условий, вы быстро получаете довольно длинный метод. Длина метода сама по себе является фактором, который затрудняет чтение, но условия усложняют задачу. Проблема обычно заключается в том, что код, как в проверке условий, так и в действиях, сообщает вам, что происходит, но может легко скрыть, почему это происходит.

Как и в случае любого большого блока кода, вы можете прояснить свое намерение, разложив его и заменив куски кода вызовом метода, названного в честь намерения этого блока кода. > С условиями вы можете получить дополнительную выгоду, выполняя это для условной части и каждой альтернативы. Таким образом, вы выдвигаете на первый план условие и четко указываете, на что вы переходите. Вы также выдвигаете на первый план причину ветвления ".

И да, его ответ также действителен для реализаций Java. Он не присваивает условную функцию переменной, хотя в примерах.

Ответ 9

Я бы подумал об этом еще в стиле старой школы C; это не очень хорошая практика в JavaScript, поэтому вам следует избегать этого.

Ответ 10

вы можете сделать что-то вроде этого:

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

Ответ 11

Я приехал сюда с Голанга, где обычно можно увидеть что-то вроде

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

В котором err распространяется до этого, if только блок. Таким образом, вот что я делаю в es6, который кажется довольно уродливым, но не делает мои довольно строгие правила eslint бледными, и достигает того же самого.

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

Дополнительные фигурные скобки определяют новую "лексическую область видимости"? Это означает, что я могу использовать const, а err недоступен для внешнего блока.