Przypisać zmienną w warunku warunkowym, dobrą praktyką czy nie? [Zamknięte]

Rok temu przeniosłem się z klasycznych języków OO, takich jak Java, na JavaScript. Poniższy kod zdecydowanie nie jest zalecany (lub nawet nieprawidłowy) w Javie:

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

Zasadniczo właśnie dowiedziałem się, że mogę przypisać zmienną do wartości w instrukcji warunku if i natychmiast sprawdzić przypisaną wartość tak, jakby była logiczna.

Dla większego bezpieczeństwa zwykle dzielę to na dwie linie kodu, najpierw przypisuję, a potem sprawdzam zmienną, ale teraz, kiedy to znalazłem, zastanawiam się tylko, czy jest to dobra praktyka w oczach doświadczonych programistów JavaScript?

Nie polecałbym tego. Problem polega na tym, że wygląda to na typowy błąd, podczas którego próbujesz porównać wartości, ale używasz pojedynczego =zamiast ==lub ===. Na przykład, gdy widzisz to:

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

nie wiesz, czy to właśnie mieli zamiar zrobić, czy też zamierzali napisać to:

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

Jeśli naprawdę chcesz wykonać zadanie na miejscu, polecam również wykonanie wyraźnego porównania:

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

Nie widzę żadnego dowodu, że to nie jest dobra praktyka. Tak, może to wyglądać na błąd, ale można to łatwo naprawić poprzez rozsądne komentarze. Weź na przykład:

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

Dlaczego ta funkcja miałaby być uruchamiana po raz drugi z:

alert(processorIntensiveFunction());

Ponieważ pierwsza wersja WYGLĄDA źle? Nie mogę zgodzić się z tą logiką.

Robiłem to wiele razy. Aby ominąć ostrzeżenie JavaScript, dodaję dwa pareny:

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

Powinieneś tego unikać, jeśli naprawdę chcesz go używać, napisz nad nim komentarz, mówiąc o tym, co robisz.

Możesz to zrobić również w Javie. I nie, to nie jest dobra praktyka. :)

(I użyj ===w Javascript do wpisania równości. Przeczytaj książkę Crockforda The Good Parts o JS.)

Jest jeden przypadek, kiedy to robisz, z while-loops.
Czytając pliki, zwykle robisz to:

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

Spójrz na while-loop w linii 9. Tam, nowa linia jest odczytywana i zapisywana w zmiennej, a następnie uruchamiana jest zawartość pętli. Wiem, że to nie jest stwierdzenie- if, ale myślę, że w twoim pytaniu można również zawrzeć pętlę while.

Powodem tego jest to, że gdy używasz a FileInputStream, za każdym razem, gdy wywołujesz FileInputStream.readLine(), odczytuje on następną linię w pliku, więc gdybyś wywołał go z pętli fileIn.readLine() != nullbez przypisywania zmiennej, zamiast wywoływać (currentLine = fileIn.readLine()) != null, a następnie wywołać go z wewnątrz pętli, dostaniesz tylko co drugą linię.

Mam nadzieję, że rozumiesz i powodzenia!

Możesz również wykonywać przypisania w instrukcjach if w języku Java. Dobrym przykładem może być przeczytanie i wypisanie czegoś:

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

Kod:

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

Gdybyś miał odnieść się do książki Martina Fowlersa Refaktoryzacja ulepszająca projekt istniejącego kodu ! Następnie jest kilka przypadków, w których byłaby to dobra praktyka, np. długie, złożone warunki warunkowe do użycia funkcji lub wywołania metody w celu potwierdzenia sprawy:

"Motywacja

Jednym z najpowszechniejszych obszarów złożoności programu jest złożona logika warunkowa. Pisząc kod do testowania warunków i robienia różnych rzeczy w zależności od różnych warunków, szybko otrzymujesz dość długą metodę. Długość metody jest sama w sobie czynnikiem utrudniającym jej odczytanie, ale warunki zwiększają trudność. Problem zwykle polega na tym, że kod, zarówno w sprawdzaniu warunków, jak iw działaniach, mówi ci, co się dzieje, ale może łatwo zaciemnić, dlaczego tak się dzieje.

Podobnie jak w przypadku każdego dużego bloku kodu, możesz wyjaśnić swój zamiar, rozkładając go i zastępując fragmenty kodu wywołaniem metody nazwanym tak, jak intencja tego bloku kodu. > W przypadku warunków możesz uzyskać dalsze korzyści, robiąc to w przypadku części warunkowej i każdej z alternatyw. W ten sposób podkreślisz warunek i jasno określisz, na czym się> rozgałęziasz. Podkreślasz również przyczynę rozgałęzienia ”.

I tak, jego odpowiedź dotyczy również implementacji języka Java. W przykładach nie przypisuje funkcji warunkowej do zmiennej.

To nie jest dobra praktyka. Wkrótce się z tym pogubisz. Wygląda podobnie do typowego błędu: niewłaściwego użycia operatorów „=” i „==”.

Powinieneś podzielić go na 2 wiersze kodów. Pomaga to nie tylko uczynić kod bardziej przejrzystym, ale także ułatwia jego refaktoryzację w przyszłości. Wyobraź sobie, że zmieniasz warunek IF? Możesz przypadkowo usunąć wiersz, a zmienna nie będzie już mieć przypisanej do niej wartości.

Uznałbym to za bardziej oldschoolowy styl C; nie jest to dobra praktyka w JavaScript, więc powinieneś jej unikać.

możesz zrobić coś takiego:

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

Przyjechałem tu z Golang, gdzie często można zobaczyć coś takiego

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

W którym errjest ograniczony tylko do tego ifbloku. W związku z tym oto, co robię w es6, co wydaje się dość brzydkie, ale nie sprawia, że ​​moje raczej surowe zasady eslinta jęczą i osiągają to samo.

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

Dodatkowe nawiasy klamrowe definiują nowy, hm, „zakres leksykalny”? Co oznacza, że ​​mogę używać consti errnie jest dostępny dla zewnętrznego bloku.