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

Год назад я перешел с классических объектно-ориентированных языков, таких как Java, на JavaScript. Следующий код определенно не рекомендуется (или даже неправильно) в 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;
}

По сути, я только что обнаружил, что могу присвоить переменной значение в операторе условия if и немедленно проверить присвоенное значение, как если бы оно было логическим.

Для большей безопасности я обычно разделяю это на две строки кода, сначала назначаю, а затем проверяю переменную, но теперь, когда я это нашел, мне просто интересно, является ли это хорошей практикой или нет в глазах опытных разработчиков JavaScript?

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

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

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

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

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

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

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

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

Почему этой функции должно быть разрешено запускаться второй раз с:

alert(processorIntensiveFunction());

Потому что первая версия ВЫГЛЯДИТ плохо? Я не могу согласиться с такой логикой.

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

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

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

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

(И используйте ===в Javascript для типизированного равенства. Прочтите книгу Крокфорда «Хорошие части» по JS.)

Есть один случай, когда вы это делаете с 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'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
        }
    }
}

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

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

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

Вы также можете выполнять присваивания внутри операторов 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();
}

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

«Мотивация

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

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

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

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

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

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

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

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

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

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

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

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

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