Призначити змінну, якщо заява про стан, хороша практика чи ні? [зачинено]

Я перейшов рік тому з класичних мов OO, таких як 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 твердження, але певний час цикл може бути також включений у ваше запитання.

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

Сподіваюся, ви зрозуміли, і удачі!

Ви також можете виконувати завдання, якщо викладати і 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();
}

Якби ви зверталися до книги Мартіна Фаулерса Refactoring, що покращує дизайн існуючого коду ! Тоді є кілька випадків, коли це було б хорошою практикою, наприклад. довгі складні умови для використання виклику функції або методу для затвердження вашого випадку:

"Мотивація

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

Як і у будь-якому великому блоці коду, ви можете зробити свій намір зрозумілішим, розклавши його та замінивши шматки коду викликом методу, названим за наміром цього блоку коду. > За умови ви можете отримати додаткову вигоду, зробивши це для умовної частини та кожної з альтернатив. Таким чином ви виділяєте умову і чітко даєте зрозуміти, на що ви> розгалужуєте. Ви також підкреслюєте причину розгалуження ".

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

Це не найкраща практика. Ви незабаром збентежитеся. Це схоже на загальну помилку: неправильне використання операторів "=" та "==".

Ви повинні розбити його на 2 рядки кодів. Це не тільки допомагає зробити код більш зрозумілим, але й легко переробляти в майбутньому. Уявіть, що ви змінюєте стан IF? Ви можете випадково видалити рядок, і ваша змінна більше не отримає призначене їй значення.

Я вважав би це більш старожитним стилем С; Це не дуже хороша практика роботи в JavaScript, тому вам слід уникати цього.

ви можете зробити щось подібне:

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

Я приїхав сюди з Голангу, де звичайно бачити щось подібне

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

У якому errрозміщено лише цей ifблок. Отож, ось що я роблю в es6, що здається досить некрасивим, але не робить моїх досить суворих правил дефіле, і домагається того ж.

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

Додаткові дужки визначають новий, е-е, "лексичний обсяг"? Що означає, що я можу використовувати const, і errнедоступний для зовнішнього блоку.