Là `break` và` continue` thực hành lập trình xấu?

Ông chủ của tôi liên tục đề cập đến việc các lập trình viên xấu sử dụng breakvà continuetrong các vòng lặp.

Tôi sử dụng chúng mọi lúc vì chúng có ý nghĩa; Hãy để tôi chỉ cho bạn cảm hứng:

function verify(object) {
    if (object->value < 0) return false;
    if (object->value > object->max_value) return false;
    if (object->name == "") return false;
    ...
}

Vấn đề ở đây là đầu tiên hàm kiểm tra các điều kiện là chính xác, sau đó thực thi chức năng thực tế. IMO tương tự áp dụng với các vòng lặp:

while (primary_condition) {
    if (loop_count > 1000) break;
    if (time_exect > 3600) break;
    if (this->data == "undefined") continue;
    if (this->skip == true) continue;
    ...
}

Tôi nghĩ rằng điều này làm cho nó dễ đọc & gỡ lỗi hơn; nhưng tôi cũng không thấy nhược điểm.

Khi được sử dụng khi bắt đầu một khối, khi kiểm tra lần đầu tiên được thực hiện, chúng hoạt động như các điều kiện tiên quyết, vì vậy nó rất tốt.

Khi được sử dụng ở giữa khối, với một số mã xung quanh, chúng hoạt động như các bẫy ẩn, vì vậy nó rất tệ.

Bạn có thể đọc Lập trình cấu trúc trên giấy năm 1974 của Donald Knuth với các Tuyên bố , trong đó ông thảo luận về các cách sử dụng khác nhau go tomà theo cấu trúc mong muốn. Chúng bao gồm tương đương breakvà các continuecâu lệnh (nhiều cách sử dụng go totrong đó đã được phát triển thành các cấu trúc hạn chế hơn). Có phải ông chủ của bạn là kiểu người gọi Knuth là một lập trình viên tồi?

(Các ví dụ được đưa lãi suất cho tôi. Thông thường, breakvà continueđang không thích bởi những người thích một bài dự thi và một lối ra từ bất kỳ đoạn mã, và đó là loại người cũng cau mày trên nhiều returnbáo cáo.)

Tôi không tin họ là xấu. Ý tưởng rằng chúng là xấu xuất phát từ những ngày lập trình có cấu trúc. Nó liên quan đến khái niệm rằng một chức năng phải có một điểm vào duy nhất và một điểm thoát duy nhất, tức là chỉ có một điểm returncho mỗi chức năng.

Điều này có ý nghĩa nếu chức năng của bạn dài và nếu bạn có nhiều vòng lặp lồng nhau. Tuy nhiên, các chức năng của bạn nên ngắn và bạn nên quấn các vòng và cơ thể của chúng thành các chức năng ngắn của riêng chúng. Nói chung, việc buộc một hàm phải có một điểm thoát duy nhất có thể dẫn đến logic rất phức tạp.

Nếu chức năng của bạn rất ngắn, nếu bạn có một vòng lặp đơn, hoặc tệ nhất là hai vòng lặp lồng nhau và nếu thân vòng lặp rất ngắn, thì rõ ràng a breakhoặc a continuelàm gì. Nó cũng rõ ràng những gì nhiều returntuyên bố làm.

Những vấn đề này được giải quyết trong "Mã sạch" của Robert C. Martin và trong "Tái cấu trúc" của Martin Fowler.

Lập trình viên xấu nói chuyện tuyệt đối (giống như Sith). Lập trình viên giỏi sử dụng giải pháp rõ ràng nhất có thể ( tất cả những thứ khác đều bằng nhau ).

Sử dụng break và tiếp tục thường xuyên làm cho mã khó theo dõi. Nhưng nếu thay thế chúng làm cho mã khó theo dõi hơn, thì đó là một thay đổi xấu.

Ví dụ bạn đưa ra chắc chắn là một tình huống trong đó nghỉ và tiếp tục nên được thay thế bằng một cái gì đó thanh lịch hơn.

Hầu hết mọi người nghĩ rằng đó là một ý tưởng tồi bởi vì hành vi không dễ dự đoán. Nếu bạn đang đọc mã và bạn thấy while(x < 1000){}bạn cho rằng nó sẽ chạy cho đến khi x> = 1000 ... Nhưng nếu có dấu ngắt ở giữa, thì điều đó không đúng, vì vậy bạn không thể thực sự tin tưởng Vòng lặp...

Đó là lý do tương tự mà mọi người không thích GOTO: chắc chắn, nó có thể được sử dụng tốt, nhưng nó cũng có thể dẫn đến mã spaghetti hợp pháp, nơi mã nhảy ngẫu nhiên từ phần này sang phần khác.

Đối với bản thân tôi, nếu tôi định thực hiện một vòng lặp phá vỡ nhiều hơn một điều kiện, thì tôi sẽ while(x){}chuyển X thành sai khi tôi cần thoát ra. Kết quả cuối cùng sẽ giống nhau và bất kỳ ai đọc qua mã cũng sẽ biết để xem xét kỹ hơn những thứ đã chuyển giá trị của X.

Có, bạn có thể [viết lại] chương trình mà không có câu lệnh break (hoặc trả về từ giữa các vòng lặp, điều này làm điều tương tự). Nhưng bạn có thể phải giới thiệu các biến bổ sung và / hoặc sao chép mã cả hai điều này thường làm cho chương trình khó hiểu hơn. Pascal (ngôn ngữ lập trình) rất tệ, đặc biệt đối với những lập trình viên mới bắt đầu vì lý do đó. Sếp của bạn về cơ bản muốn bạn lập trình trong các cấu trúc điều khiển của Pascal. Nếu Linus Torvalds ở trong đôi giày của bạn, anh ta có thể sẽ cho ông chủ của bạn xem ngón tay giữa!

Có một kết quả khoa học máy tính được gọi là hệ thống cấu trúc điều khiển của Kosaraju, xuất hiện từ năm 1973 và được đề cập trong bài báo nổi tiếng của Knuth trên gotos từ năm 1974. (Nhân tiện, bài báo này của Knuth đã được David Thornley đề xuất ở trên .) Điều S. Rao Kosaraju đã chứng minh vào năm 1973 là không thể viết lại tất cả các chương trình có độ sâu đa cấp độ sâu n thành các chương trình có độ sâu phá vỡ nhỏ hơn n mà không đưa ra các biến phụ. Nhưng hãy nói rằng đó chỉ là một kết quả lý thuyết đơn thuần. (Chỉ cần thêm một vài biến số?! Chắc chắn bạn có thể làm điều đó để làm hài lòng sếp của bạn ...)

Điều quan trọng hơn nhiều từ góc độ công nghệ phần mềm là một bài báo gần đây hơn năm 1995 của Eric S. Roberts có tựa đề Thoát khỏi vòng lặp và lập trình có cấu trúc: Mở lại cuộc tranh luận ( http://cs.stanford.edu/people/eroberts/ con / SIGCSE- 1995 / LoopExits.pdf ). Roberts tóm tắt một số nghiên cứu thực nghiệm được thực hiện bởi những người khác trước ông. Ví dụ, khi một nhóm sinh viên loại CS101 được yêu cầu viết mã cho một hàm thực hiện tìm kiếm tuần tự trong một mảng, tác giả của nghiên cứu đã nói như sau về những sinh viên đã sử dụng break / return / goto để thoát khỏi vòng tìm kiếm tuần tự khi tìm thấy phần tử:

Tôi vẫn chưa tìm thấy một người nào đã thử một chương trình sử dụng [kiểu này], người đã tạo ra một giải pháp không chính xác.

Roberts cũng nói rằng:

Những sinh viên đã cố gắng giải quyết vấn đề mà không sử dụng một kết quả rõ ràng từ vòng lặp for thì kém hơn rất nhiều: chỉ có bảy trong số 42 sinh viên cố gắng chiến lược này quản lý để tạo ra các giải pháp chính xác. Con số đó thể hiện tỷ lệ thành công dưới 20%.

Có, bạn có thể có nhiều kinh nghiệm hơn sinh viên CS101, nhưng không sử dụng câu lệnh break (hoặc trả lại / goto tương đương từ giữa các vòng lặp), cuối cùng bạn sẽ viết mã mà trong khi có cấu trúc độc đáo là đủ lông về mặt logic bổ sung các biến và sao chép mã mà ai đó, có thể là chính bạn, sẽ đặt các lỗi logic trong đó trong khi cố gắng làm theo kiểu mã hóa của sếp.

Tôi cũng sẽ nói ở đây rằng bài viết của Roberts dễ tiếp cận hơn với các lập trình viên trung bình, vì vậy lần đọc đầu tiên tốt hơn Knuth. Nó cũng ngắn hơn và bao gồm một chủ đề hẹp hơn. Bạn thậm chí có thể giới thiệu nó cho sếp của mình, ngay cả khi anh ta là quản lý chứ không phải là loại CS.

Tôi không xem xét sử dụng một trong những thực hành xấu này, nhưng sử dụng chúng quá nhiều trong cùng một vòng lặp sẽ đảm bảo xem xét lại logic được sử dụng trong vòng lặp. Sử dụng chúng một cách tiết kiệm.

Ví dụ bạn đưa ra không cần nghỉ cũng không tiếp tục:

while (primary-condition AND
       loop-count <= 1000 AND
       time-exec <= 3600) {
   when (data != "undefined" AND
           NOT skip)
      do-something-useful;
   }

"Vấn đề" của tôi với 4 dòng trong ví dụ của bạn là tất cả chúng đều ở cùng cấp độ nhưng chúng làm những việc khác nhau: một số nghỉ, một số tiếp tục ... Bạn phải đọc từng dòng.

Theo cách tiếp cận lồng nhau của tôi, bạn càng đi sâu, mã càng trở nên 'hữu ích'.

Nhưng, nếu sâu bên trong bạn sẽ tìm thấy một lý do để dừng vòng lặp (không phải là điều kiện chính), thì việc ngắt hoặc trả lại sẽ được sử dụng. Tôi muốn sử dụng một cờ bổ sung sẽ được kiểm tra trong điều kiện cấp cao nhất. Việc nghỉ / trả lại trực tiếp hơn; nó tốt hơn nêu ý định hơn là thiết lập một biến khác.

"Tính xấu" phụ thuộc vào cách bạn sử dụng chúng. Tôi thường sử dụng các ngắt trong các cấu trúc lặp CHỈ khi nó sẽ tiết kiệm cho tôi các chu kỳ không thể lưu thông qua việc tái cấu trúc thuật toán. Chẳng hạn, đạp xe qua bộ sưu tập tìm kiếm một vật phẩm có giá trị trong một thuộc tính cụ thể được đặt thành đúng. Nếu tất cả những gì bạn cần biết là một trong những mục có thuộc tính này được đặt thành đúng, một khi bạn đạt được kết quả đó, việc ngắt kết thúc vòng lặp là thích hợp.

Nếu sử dụng dấu ngắt sẽ không làm cho mã dễ đọc hơn, ngắn hơn để chạy hoặc lưu chu kỳ xử lý theo cách đáng kể, thì tốt nhất không nên sử dụng chúng. Tôi có xu hướng mã hóa thành "mẫu số chung thấp nhất" khi có thể để đảm bảo rằng bất kỳ ai theo dõi tôi đều có thể dễ dàng xem mã của tôi và tìm hiểu điều gì đang xảy ra (tôi không phải lúc nào cũng thành công trong việc này). Phá vỡ điều đó bởi vì họ giới thiệu điểm vào / ra lẻ. Bị lạm dụng, họ có thể cư xử rất giống với một tuyên bố "goto".

Hoàn toàn không ... Có, việc sử dụng gotolà xấu vì nó làm hỏng cấu trúc chương trình của bạn và cũng rất khó để hiểu được dòng điều khiển.

Nhưng việc sử dụng các tuyên bố như breakvà continuehoàn toàn cần thiết trong những ngày này và không được coi là thực hành lập trình xấu cả.

Và cũng không khó để hiểu được dòng điều khiển sử dụng breakvà continue. Trong cấu trúc như switchcác breaktuyên bố là hoàn toàn cần thiết.

Khái niệm thiết yếu đến từ việc có thể phân tích ngữ nghĩa chương trình của bạn. Nếu bạn có một mục duy nhất và một lối thoát duy nhất, toán học cần thiết để biểu thị các trạng thái có thể dễ dàng hơn đáng kể so với việc bạn phải quản lý các đường dẫn.

Một phần, khó khăn này phản ánh khả năng lý luận về mã của bạn về mặt khái niệm.

Thành thật mà nói, mã thứ hai của bạn không rõ ràng. Nó đang làm gì vậy Liệu tiếp tục 'tiếp tục', hay nó 'tiếp theo' vòng lặp? Tôi không có ý kiến. Ít nhất là ví dụ đầu tiên của bạn là rõ ràng.

Tôi sẽ thay thế đoạn mã thứ hai của bạn bằng

while (primary_condition && (loop_count <= 1000 && time_exect <= 3600)) {
    if (this->data != "undefined" && this->skip != true) {
        ..
    }
}

không vì bất kỳ lý do nào của sự căng thẳng - tôi thực sự nghĩ rằng điều này dễ đọc hơn và để ai đó hiểu những gì đang xảy ra. Nói chung, các điều kiện cho các vòng lặp của bạn nên được chứa hoàn toàn trong các điều kiện vòng lặp không được xả rác khắp cơ thể. Tuy nhiên, có một số tình huống breakvà continuecó thể giúp dễ đọc. breakmoreso hơn continuetôi có thể thêm: D

Tôi không đồng ý với sếp của bạn. Có những nơi thích hợp cho breakvà continueđược sử dụng. Trong thực tế, lý do mà việc thực thi và xử lý ngoại lệ được đưa vào các ngôn ngữ lập trình hiện đại là bạn không thể giải quyết mọi vấn đề bằng cách sử dụng structured techniques.

Bên cạnh đó, tôi không muốn bắt đầu một cuộc thảo luận tôn giáo ở đây nhưng bạn có thể cơ cấu lại mã của mình để dễ đọc hơn như thế này:

while (primary_condition) {
    if (loop_count > 1000) || (time_exect > 3600) {
        break;
    } else if ( ( this->data != "undefined") && ( !this->skip ) ) {
       ... // where the real work of the loop happens
    }
}

Mặt khác

Cá nhân tôi không thích việc sử dụng ( flag == true )trong các điều kiện bởi vì nếu biến đã là boolean rồi, thì bạn đang đưa ra một so sánh bổ sung cần xảy ra khi giá trị của boolean có câu trả lời bạn muốn - trừ khi bạn chắc chắn rằng trình biên dịch của bạn sẽ tối ưu hóa so sánh thêm đi.

Tôi đồng ý với sếp của bạn. Chúng là xấu bởi vì chúng tạo ra các phương pháp có độ phức tạp chu kỳ cao. Những phương pháp như vậy rất khó đọc và khó kiểm tra. May mắn thay, có một giải pháp dễ dàng. Trích xuất phần thân vòng lặp thành một phương thức riêng biệt, trong đó "tiếp tục" trở thành "trở lại". "Trả lại" sẽ tốt hơn vì sau khi "trả lại" nó đã kết thúc - không phải lo lắng về tình trạng địa phương.

Đối với "break" trích xuất chính vòng lặp thành một phương thức riêng biệt, thay thế "break" bằng "return".

Nếu các phương thức được trích xuất yêu cầu một số lượng lớn các đối số, thì đó là một dấu hiệu để trích xuất một lớp - hoặc thu thập chúng vào một đối tượng ngữ cảnh.

Tôi nghĩ đó chỉ là một vấn đề khi được lồng sâu bên trong nhiều vòng lặp. Thật khó để biết bạn đang phá vỡ vòng lặp nào. Có thể khó theo dõi tiếp, nhưng tôi nghĩ nỗi đau thực sự đến từ những lần nghỉ - logic có thể khó theo dõi.

Miễn là chúng không được sử dụng như goto trá hình như trong ví dụ sau:

do
{
      if (foo)
      {
             /*** code ***/
             break;
      }

      if (bar)
      {
             /*** code ***/
             break;
      }
} while (0);

Tôi ổn với họ. (Ví dụ nhìn thấy trong mã sản xuất, meh)

Tôi không thích một trong hai phong cách này. Đây là những gì tôi muốn:

function verify(object)
{
    if not (object->value < 0) 
       and not(object->value > object->max_value)
       and not(object->name == "") 
       {
         do somethign important
       }
    else return false; //probably not necessary since this function doesn't even seem to be defined to return anything...?
}

Tôi thực sự không thích sử dụng returnđể hủy bỏ một chức năng. Nó cảm thấy như một sự lạm dụng return.

Sử dụng breakcũng không phải lúc nào cũng rõ ràng để đọc.

Tốt hơn nữa có thể là:

notdone := primarycondition    
while (notDone)
{
    if (loop_count > 1000) or (time_exect > 3600)
    {
       notDone := false; 
    }
    else
    { 
        skipCurrentIteration := (this->data == "undefined") or (this->skip == true) 

        if not skipCurrentIteration
        {
           do something
        } 
        ...
    }
}

ít lồng nhau hơn và các điều kiện phức tạp được tái cấu trúc thành các biến (trong một chương trình thực, bạn phải có tên tốt hơn, rõ ràng ...)

(Tất cả các mã trên là mã giả)

Không. Đó là một cách để giải quyết vấn đề, và có nhiều cách khác để giải quyết nó.

Nhiều ngôn ngữ chính hiện tại (Java, .NET (C # + VB), PHP, viết riêng của bạn) sử dụng "break" và "continue" để bỏ qua các vòng lặp. Cả hai câu "cấu trúc goto (s)".

Không có họ:

String myKey = "mars";

int i = 0; bool found = false;
while ((i < MyList.Count) && (not found)) {
  found = (MyList[i].key == myKey);
  i++;   
}
if (found)
  ShowMessage("Key is " + i.toString());
else
  ShowMessage("Not found.");

Với họ:

String myKey = "mars";

for (i = 0; i < MyList.Count; i++) {
  if (MyList[i].key == myKey)
    break;
}
ShowMessage("Key is " + i.toString());

Lưu ý rằng, mã "phá vỡ" và "tiếp tục" ngắn hơn và thường biến các câu "trong khi" thành "cho" hoặc "foreach".

Cả hai trường hợp là một vấn đề của phong cách mã hóa. Tôi không thích sử dụng chúng , bởi vì kiểu dài cho phép tôi có nhiều quyền kiểm soát mã hơn.

Tôi thực sự, làm việc trong một số dự án, trong đó bắt buộc phải sử dụng những câu đó.

Một số nhà phát triển có thể nghĩ rằng họ không phải là necesarilly, nhưng theo giả thuyết, nếu chúng tôi phải loại bỏ chúng, chúng tôi phải xóa "while" và "do while" ("lặp lại cho đến khi", các bạn pascal) cũng vậy ;-)

Kết luận, ngay cả khi tôi không thích sử dụng chúng, tôi nghĩ đó là một lựa chọn, không phải là một thực hành lập trình tồi.

Tôi không chống lại continuevà breakvề nguyên tắc, nhưng tôi nghĩ rằng chúng là những cấu trúc cấp thấp mà rất thường có thể được thay thế bằng một thứ thậm chí còn tốt hơn.

Tôi đang sử dụng C # làm ví dụ ở đây, xem xét trường hợp muốn lặp lại bộ sưu tập, nhưng chúng tôi chỉ muốn các yếu tố đáp ứng một số vị ngữ và chúng tôi không muốn thực hiện nhiều hơn tối đa 100 lần lặp.

for (var i = 0; i < collection.Count; i++)
{
    if (!Predicate(item)) continue;
    if (i >= 100) break; // at first I used a > here which is a bug. another good thing about the more declarative style!

    DoStuff(item);
}

Cái này trông thật sạch sẽ. Nó không quá khó hiểu. Tôi nghĩ rằng nó sẽ đứng để đạt được rất nhiều từ việc tuyên bố nhiều hơn mặc dù. So sánh nó với những điều sau đây:

foreach (var item in collection.Where(Predicate).Take(100))
    DoStuff(item);

Có lẽ các cuộc gọi Where và Take thậm chí không nên theo phương thức này. Có lẽ việc lọc này nên được thực hiện TRƯỚC KHI bộ sưu tập được truyền cho phương thức này. Dù sao, bằng cách di chuyển khỏi các công cụ cấp thấp và tập trung nhiều hơn vào logic kinh doanh thực tế, nó càng trở nên rõ ràng hơn những gì chúng tôi THỰC SỰ quan tâm. Việc tách mã của chúng tôi thành các mô đun gắn kết tuân thủ nhiều hơn các thực tiễn thiết kế tốt và vì vậy trên, bật.

Các công cụ cấp thấp vẫn sẽ tồn tại trong một số phần của mã, nhưng chúng tôi muốn che giấu điều này càng nhiều càng tốt, vì nó cần năng lượng tinh thần mà chúng tôi có thể sử dụng để lý giải về các vấn đề kinh doanh thay thế.

Code Complete có một phần hay về cách sử dụng gotovà nhiều trả về từ thường trình hoặc vòng lặp.

Nói chung nó không phải là thực hành xấu. breakhoặc continuenói chính xác những gì xảy ra tiếp theo. Và tôi đồng ý với điều này.

Steve McConnell (tác giả của Code Complete) sử dụng gần như các ví dụ giống như bạn để thể hiện lợi thế của việc sử dụng các gotocâu lệnh khác nhau .

Tuy nhiên, quá lạm dụng breakhoặc continuecó thể dẫn đến phần mềm phức tạp và không thể nhầm lẫn.