Gán biến trong câu lệnh if, thực hành tốt hay không? [đóng cửa]

Một năm trước, tôi đã chuyển từ các ngôn ngữ OO cổ điển như Java sang JavaScript. Mã sau chắc chắn không được khuyến nghị (hoặc thậm chí không đúng) trong 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;
}

Về cơ bản, tôi vừa phát hiện ra rằng tôi có thể gán một biến cho một giá trị trong câu lệnh điều kiện if và ngay lập tức kiểm tra giá trị được gán như thể nó là boolean.

Để đặt cược an toàn hơn, tôi thường tách nó thành hai dòng mã, gán trước sau đó kiểm tra biến, nhưng bây giờ tôi tìm thấy điều này, tôi chỉ tự hỏi liệu nó có phải là phương pháp tốt hay không dưới con mắt của các nhà phát triển JavaScript có kinh nghiệm?

Tôi sẽ không giới thiệu nó. Vấn đề là, có vẻ như một lỗi phổ biến khi bạn cố gắng so sánh các giá trị nhưng sử dụng một giá trị =thay vì ==hoặc ===. Ví dụ, khi bạn thấy điều này:

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

bạn không biết đó có phải là những gì họ muốn làm hay họ định viết điều này:

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

Nếu bạn thực sự muốn thực hiện nhiệm vụ tại chỗ, tôi cũng khuyên bạn nên thực hiện một phép so sánh rõ ràng:

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

Tôi không thấy bằng chứng nào cho thấy đó là một thực hành không tốt. Có, nó có thể trông giống như một sai lầm nhưng điều đó có thể dễ dàng khắc phục bằng cách nhận xét một cách thận trọng. Lấy ví dụ:

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

Tại sao hàm đó nên được phép chạy lần thứ 2 với:

alert(processorIntensiveFunction());

Vì phiên bản đầu tiên LOOKS xấu? Tôi không thể đồng ý với logic đó.

Tôi đã làm điều đó nhiều lần. Để bỏ qua cảnh báo JavaScript, tôi thêm hai parens:

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

Bạn nên tránh nó, nếu bạn thực sự muốn sử dụng nó, hãy viết bình luận bên trên nó cho biết bạn đang làm gì.

Bạn cũng có thể làm điều này trong Java. Và không, đó không phải là một thực hành tốt. :)

(Và sử dụng ===trong Javascript để nhập bình đẳng. Đọc cuốn sách Những phần hay của Crockford trên JS.)

Có một trường hợp khi bạn làm điều đó, với while-loops.
Khi đọc tệp, bạn thường làm như thế này:

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

Nhìn vào while-loop ở dòng 9. Tại đó, một dòng mới được đọc và lưu trữ trong một biến, sau đó nội dung của vòng lặp được chạy. Tôi biết đây không phải là mộtif -statement, nhưng tôi đoán một vòng lặp while cũng có thể được đưa vào câu hỏi của bạn.

Lý do là khi sử dụng a FileInputStream, mỗi khi bạn gọi FileInputStream.readLine(), nó sẽ đọc dòng tiếp theo trong tệp, vì vậy nếu bạn đã gọi nó từ vòng lặp fileIn.readLine() != nullmà không cần gán biến, thay vì gọi(currentLine = fileIn.readLine()) != null , và sau đó gọi nó từ bên trong vòng lặp, bạn sẽ chỉ nhận được mỗi dòng thứ hai.

Hy vọng bạn hiểu, và chúc may mắn!

Bạn cũng có thể thực hiện các phép gán trong câu lệnh if trong Java. Một ví dụ điển hình là đọc một cái gì đó và viết nó ra:

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

Mật mã:

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

Nếu bạn đã tham khảo cuốn sách Refactoring của Martin Fowlers cải thiện thiết kế của mã hiện có ! Sau đó, có một số trường hợp mà nó sẽ là thực hành tốt, ví dụ. các điều kiện phức tạp dài để sử dụng một hàm hoặc phương thức gọi để xác nhận trường hợp của bạn:

"Động lực

Một trong những khu vực phức tạp phổ biến nhất trong chương trình nằm ở logic điều kiện phức tạp. Khi bạn viết mã để kiểm tra các điều kiện và thực hiện nhiều thứ khác nhau tùy thuộc vào các điều kiện khác nhau, bạn nhanh chóng kết thúc với một phương pháp khá dài. Độ dài của một phương pháp tự nó là một yếu tố làm cho nó khó đọc hơn, nhưng các điều kiện làm tăng độ khó. Vấn đề thường nằm ở chỗ mã, cả trong kiểm tra điều kiện và trong các hành động, cho bạn biết điều gì xảy ra nhưng có thể dễ dàng che khuất lý do tại sao nó xảy ra.

Như với bất kỳ khối mã lớn nào, bạn có thể làm cho ý định của mình rõ ràng hơn bằng cách phân tách nó và thay thế các đoạn mã bằng một lệnh gọi phương thức được đặt tên theo ý định của khối mã đó. > Với các điều kiện, bạn có thể nhận được thêm lợi ích bằng cách làm điều này cho phần có điều kiện và từng lựa chọn thay thế. Bằng cách này, bạn làm nổi bật điều kiện và làm cho nó rõ ràng những gì bạn> đang phân nhánh. Bạn cũng nêu rõ lý do phân nhánh. "

Và có câu trả lời của anh ấy cũng hợp lệ cho các triển khai Java. Nó không gán hàm điều kiện cho một biến mặc dù trong các ví dụ.

Đó không phải là thực hành tốt. Bạn sẽ sớm nhầm lẫn về nó. Nó trông giống với một lỗi phổ biến: sử dụng sai các toán tử "=" và "==".

Bạn nên chia nó thành 2 dòng mã. Nó không chỉ giúp làm cho mã rõ ràng hơn mà còn dễ dàng cấu trúc lại trong tương lai. Hãy tưởng tượng rằng bạn thay đổi điều kiện IF? Bạn có thể vô tình xóa dòng và biến của bạn không còn nhận được giá trị được gán cho nó nữa.

Tôi sẽ coi đây là một phong cách C kiểu cũ; nó không thực sự tốt trong JavaScript, vì vậy bạn nên tránh nó.

bạn có thể làm điều gì đó như vậy:

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

Tôi đến đây từ golang, nơi thường thấy những thứ như

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

Trong đó errchỉ phạm vi cho ifkhối đó . Như vậy, đây là những gì tôi đang làm trong es6, có vẻ khá xấu, nhưng không làm thay đổi các quy tắc eslint khá nghiêm ngặt của tôi và đạt được điều tương tự.

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

Dấu ngoặc nhọn bổ sung xác định một "phạm vi từ vựng" mới, uh,? Có nghĩa là tôi có thể sử dụng constvà errkhông có sẵn cho khối bên ngoài.