Điều này biện minh cho tuyên bố goto?

Tôi đã bắt gặp câu hỏi này một giây trước và tôi đang rút một số tài liệu ra khỏi đó: Có tên nào cho cấu trúc 'break n' không?

Đây dường như là một cách phức tạp không cần thiết để mọi người phải hướng dẫn chương trình thoát ra khỏi vòng lặp lồng nhau kép:

for (i = 0; i < 10; i++) {
    bool broken = false;
    for (j = 10; j > 0; j--) {
        if (j == i) {
            broken = true;
            break;
        }
    }
    if (broken)
        break;
}

Tôi biết sách giáo khoa muốn nói các tuyên bố goto là ma quỷ, và bản thân tôi không thích chúng, nhưng điều này có biện minh cho một ngoại lệ cho quy tắc này không?

Tôi đang tìm kiếm câu trả lời liên quan đến n-lồng cho các vòng lặp.

LƯU Ý: Cho dù bạn trả lời có, không, hoặc ở đâu đó ở giữa, các câu trả lời hoàn toàn gần gũi đều không được chào đón. Đặc biệt nếu câu trả lời là không, thì hãy cung cấp một lý do chính đáng, hợp lý tại sao (điều này không quá xa so với quy định của Stack Exchange).

Nhu cầu rõ ràng cho một tuyên bố đi đến phát sinh từ việc bạn chọn các biểu thức điều kiện kém cho các vòng lặp .

Bạn nói rằng bạn muốn vòng lặp bên ngoài tiếp tục miễn là vòng lặp i < 10trong cùng tiếp tục miễn là j > 0.

Nhưng trong thực tế đó không phải là điều bạn muốn , bạn chỉ đơn giản là không nói với các vòng lặp tình trạng thực mà bạn muốn họ đánh giá, sau đó bạn muốn giải quyết nó bằng cách sử dụng break hoặc goto.

Nếu bạn nói với các vòng lặp ý định thực sự của bạn để bắt đầu , thì không cần phải nghỉ hoặc goto.

bool alsoThis = true;
for (i = 0; i < 10 && alsoThis; i++)
{    
    for (j = 10; j > 0 && alsoThis; j--)
    {
        if (j == i)
        {
            alsoThis = false;
        }
    }
}

Trong trường hợp này, bạn có thể cấu trúc lại mã thành một thói quen riêng, và sau đó chỉ returntừ vòng lặp bên trong. Điều đó sẽ phủ nhận sự cần thiết phải thoát ra khỏi vòng lặp bên ngoài:

bool isBroken() {
    for (i = 0; i < 10; i++)
        for (j = 10; j > 0; j--)
            if (j == i) return true;

    return false;
}

Không, tôi không nghĩ gotolà cần thiết. Nếu bạn viết nó như thế này:

bool broken = false;
saved_i = 0;
for (i = 0; i < 10 && !broken; i++)
{
    broken = false;
    for (j = 10; j > 0 && !broken; j--)
    {
        if (j == i)
        {
            broken = true;
            saved_i = i;
        }
    }
}

Có &&!brokentrên cả hai vòng cho phép bạn thoát ra khỏi cả hai vòng khi i==j.

Đối với tôi, cách tiếp cận này là thích hợp hơn. Các điều kiện vòng lặp cực kỳ rõ ràng : i<10 && !broken.

Có thể xem phiên bản làm việc tại đây: http://rextester.com/KFMH48414

Mã số:

public static void main(String args[])
{
    int i=0;
    int j=0;
    boolean broken = false;
    for (i = 0; i < 10 && !broken; i++)
    {
        broken = false;
        for (j = 10; j > 0 && !broken; j--)
        {
            if (j == i)
            {
                broken = true;
                System.out.println("loop breaks when i==j=="+i);
            }
        }
    }
    System.out.println(i);
    System.out.println(j);
}

Đầu ra:

vòng lặp bị phá vỡ khi i == j == 1
2
0

Câu trả lời ngắn gọn là "nó phụ thuộc". Tôi ủng hộ để lựa chọn về mức độ dễ đọc và dễ hiểu của mã của bạn. Cách goto có thể dễ đọc hơn điều chỉnh điều kiện hoặc ngược lại. Bạn cũng có thể tính đến nguyên tắc ít bất ngờ nhất, hướng dẫn được sử dụng trong cửa hàng / dự án và tính nhất quán của cơ sở mã. Chẳng hạn, goto rời khỏi switch hoặc để xử lý lỗi là một cách làm phổ biến trong cơ sở mã hạt nhân Linux. Cũng lưu ý rằng một số lập trình viên có thể gặp vấn đề khi đọc mã của bạn (hoặc được nêu lên với câu thần chú "goto là ác" hoặc không học vì giáo viên của họ nghĩ vậy) và một vài trong số họ thậm chí có thể "phán xét bạn".

Nói chung, một goto đi xa hơn trong cùng một chức năng thường được chấp nhận, đặc biệt là nếu bước nhảy không quá dài. Trường hợp sử dụng của bạn để lại một vòng lặp lồng nhau là một trong những ví dụ đã biết của goto "không quá ác".

Trong trường hợp của bạn, goto là một cải tiến đủ để trông hấp dẫn, nhưng nó không phải là một cải tiến quá đáng để phá vỡ quy tắc chống lại việc sử dụng chúng trong cơ sở mã của bạn.

Hãy nghĩ về người đánh giá trong tương lai của bạn: anh ấy sẽ phải suy nghĩ: "Người này có phải là một lập trình viên tồi hay thực tế đây là một trường hợp mà goto đáng giá không? Hãy để tôi dành 5 phút để tự mình quyết định hoặc nghiên cứu về nó Internet." Tại sao bạn lại làm điều đó với lập trình viên tương lai của mình khi bạn không thể sử dụng hoàn toàn goto?

Nói chung, tâm lý này áp dụng cho tất cả các mã "xấu" và thậm chí định nghĩa nó: nếu nó hoạt động ngay bây giờ và tốt trong trường hợp này, nhưng tạo ra nỗ lực để xác minh nó là chính xác, trong thời đại này, một goto sẽ luôn làm, sau đó không làm đi.

Điều đó đang được nói, vâng, bạn đã sản xuất một trong những trường hợp hơi gai góc. Bạn có thể:

• sử dụng các cấu trúc điều khiển phức tạp hơn, như cờ boolean, để thoát ra khỏi cả hai vòng
• đặt vòng lặp bên trong của bạn bên trong thói quen của riêng nó (có thể là lý tưởng)
• đặt cả hai vòng trong một thói quen và trở lại thay vì phá vỡ

Thật khó cho tôi để tạo ra một trường hợp trong đó một vòng lặp đôi không gắn kết đến mức dù sao nó cũng không phải là thói quen của riêng nó.

Nhân tiện, cuộc thảo luận tốt nhất về điều này tôi đã thấy là Hoàn thành mã của Steve McConnell . Nếu bạn thích suy nghĩ về những vấn đề này một cách nghiêm túc, tôi thực sự khuyên bạn nên đọc, thậm chí là che đậy mặc dù nó rất lớn.

TLD; DR: Không cụ thể, có nói chung

Đối với ví dụ cụ thể bạn đã sử dụng, tôi sẽ nói không vì những lý do tương tự mà nhiều người khác đã chỉ ra. Bạn có thể dễ dàng cấu trúc lại mã thành một hình thức tương đương tốt mà không cần phải có goto.

Nói chung, công tố chống lại gotolà một tổng quát dựa trên bản chất được hiểu gotovà chi phí sử dụng nó. Một phần của công nghệ phần mềm đang đưa ra quyết định thực hiện. Biện minh cho những quyết định đó xảy ra bằng cách cân nhắc chi phí với lợi ích và bất cứ khi nào lợi ích lớn hơn chi phí thì việc thực hiện là hợp lý. Tranh cãi nảy sinh vì định giá khác nhau, cả về chi phí và lợi ích.

Vấn đề là sẽ luôn có những trường hợp ngoại lệ trong đó a gotolà hợp lý, nhưng chỉ đối với một số vì định giá khác nhau. Điều đáng tiếc là nhiều kỹ sư chỉ đơn giản loại trừ các kỹ thuật trong sự thiếu hiểu biết có chủ đích vì họ đọc nó trên internet thay vì dành thời gian để hiểu lý do tại sao.

Tôi không nghĩ trường hợp này biện minh cho một ngoại lệ, vì điều này có thể được viết là:

def outerLoop(){
    for (i = 0; i < 10; i++) {
        if( broken?(i) )
          return; // broken
    }
}

def broken?(i){
   for (j = 10; j > 0; j--) {
        if (j == i) {
            return true; // broken
        }
   }
   return false; // not broken
}