Trong vòng lặp for, tôi có nên chuyển điều kiện ngắt vào trường điều kiện nếu có thể không? [đóng cửa]

Đôi khi tôi cần những vòng lặp cần nghỉ ngơi như thế này:

for(int i=0;i<array.length;i++){
    //some other code
    if(condition){
        break;
    }
}

Tôi cảm thấy không thoải mái với việc viết

if(condition){
    break;
}

bởi vì nó tiêu thụ 3 dòng mã. Và tôi thấy vòng lặp có thể được viết lại thành:

                                   ↓
for(int i=0;i<array.length && !condition;i++){
    //some other code
}

Vì vậy, câu hỏi của tôi là, có nên thực hiện tốt việc chuyển điều kiện vào trường điều kiện để giảm các dòng mã nếu có thể?

Hai ví dụ bạn đưa ra không tương đương về chức năng. Trong bản gốc, kiểm tra điều kiện được thực hiện sau phần "một số mã khác", trong khi ở phiên bản sửa đổi, nó được thực hiện trước, khi bắt đầu thân vòng lặp.

Mã không bao giờ được viết lại với mục đích duy nhất là giảm số lượng dòng. Rõ ràng đó là một phần thưởng tuyệt vời khi nó hoạt động theo cách đó, nhưng nó không bao giờ nên được thực hiện với chi phí dễ đọc hoặc chính xác.

Tôi không mua lập luận rằng "nó tiêu thụ 3 dòng mã" và do đó là xấu. Rốt cuộc, bạn chỉ có thể viết nó như sau:

if (condition) break;

và chỉ tiêu thụ một dòng.

Nếu ifxuất hiện một nửa trong vòng lặp, tất nhiên nó phải tồn tại như một thử nghiệm riêng biệt. Tuy nhiên, nếu kiểm tra này xuất hiện ở cuối khối, bạn đã tạo một vòng lặp có kiểm tra tiếp tục ở cả hai đầu của vòng lặp, có thể thêm vào độ phức tạp của mã. Mặc dù vậy, hãy lưu ý rằng đôi khi if (condition)thử nghiệm chỉ có thể có ý nghĩa sau khi khối đã được thực thi.

Nhưng giả sử đó không phải là trường hợp, bằng cách áp dụng phương pháp khác:

for(int i=0;i<array.length && !condition;i++){
    //some other code
}

các điều kiện thoát được giữ cùng nhau, điều này có thể đơn giản hóa mọi thứ (đặc biệt nếu " một số mã khác " dài).

Tất nhiên không có câu trả lời đúng ở đây. Vì vậy, hãy lưu ý đến các thành ngữ của ngôn ngữ, các quy ước mã hóa của nhóm bạn là gì, v.v. Nhưng để cân bằng, tôi sẽ áp dụng phương pháp thử nghiệm duy nhất khi nó có ý nghĩa chức năng để làm như vậy.

Loại câu hỏi này đã gây ra cuộc tranh luận gần như là lập trình. Để ném mũ vào vòng, tôi sẽ chọn phiên bản với breakđiều kiện và đây là lý do (đối với trường hợp cụ thể này):

Các forvòng lặp chỉ là có để xác định các giá trị lặp trong vòng lặp. Mã hóa điều kiện phá vỡ trong đó chỉ làm mờ IMO logic.

Có một phân tách breakrõ ràng rằng trong quá trình xử lý thông thường, các giá trị được chỉ định trong forvòng lặp và quá trình xử lý sẽ tiếp tục ngoại trừ khi điều kiện xuất hiện.

Để làm nền tảng, tôi bắt đầu viết mã a break, sau đó đặt điều kiện vào forvòng lặp trong nhiều năm (dưới sự chỉ đạo của một lập trình viên đặc biệt) và sau đó quay trở lại breakphong cách vì nó chỉ cảm thấy sạch hơn (và là phong cách thịnh hành trong các bộ mã khác nhau tôi đã tiêu thụ).

Đó là một trong những cuộc chiến thần thánh vào cuối ngày - một số người nói rằng bạn không bao giờ nên thoát ra khỏi một vòng lặp một cách giả tạo, nếu không đó không phải là một vòng lặp thực sự. Làm bất cứ điều gì bạn cảm thấy có thể đọc được (cả cho bản thân và người khác). Nếu việc giảm tổ hợp phím thực sự là việc của bạn, hãy chơi golf vào cuối tuần - bia tùy chọn.

forcác vòng lặp là để lặp đi lặp lại một cái gì đó ¹ - chúng không chỉ là lol-let-pull-some-Random-Stuff-from-the-body-and-put-them-in-the-loop-header - ba biểu thức có rất ý nghĩa cụ thể:

• Cái đầu tiên là để khởi tạo iterator . Nó có thể là một chỉ mục, một con trỏ, một đối tượng lặp hoặc bất cứ điều gì - miễn là nó được sử dụng để lặp lại .
• Thứ hai là để kiểm tra nếu chúng ta đạt đến cuối.
• Thứ ba là để thúc đẩy các vòng lặp.

Ý tưởng là để tách việc xử lý lặp đi lặp lại ( như thế nào để lặp) từ logic bên trong vòng lặp ( những gì cần làm trong mỗi lần lặp). Nhiều ngôn ngữ thường có một vòng lặp cho mỗi vòng lặp giúp bạn thoát khỏi các chi tiết của vòng lặp, nhưng ngay cả khi ngôn ngữ của bạn không có cấu trúc đó hoặc nếu nó không thể được sử dụng trong kịch bản của bạn - bạn vẫn nên giới hạn tiêu đề vòng lặp để xử lý lặp đi lặp lại.

Vì vậy, bạn cần phải tự hỏi mình - là điều kiện của bạn về việc xử lý lặp hoặc về logic bên trong vòng lặp? Rất có thể, đó là về logic bên trong vòng lặp - vì vậy nó nên được kiểm tra bên trong vòng lặp chứ không phải trong tiêu đề.

¹ Trái ngược với các vòng lặp khác, đó là "chờ đợi" điều gì đó xảy ra. Một vòng lặp for/ foreachnên có khái niệm về một "danh sách" các mục để lặp lại - ngay cả khi danh sách đó là lười biếng hoặc vô hạn hoặc trừu tượng.

Tôi khuyên bạn nên sử dụng phiên bản với if (condition). Nó dễ đọc hơn và dễ gỡ lỗi hơn. Viết thêm 3 dòng mã sẽ không làm gãy ngón tay của bạn, nhưng sẽ giúp người tiếp theo hiểu mã của bạn dễ dàng hơn.

Nếu bạn đang lặp lại một bộ sưu tập trong đó các yếu tố nhất định nên được bỏ qua, thì tôi khuyên bạn nên sử dụng một tùy chọn mới:

• Lọc bộ sưu tập của bạn trước khi lặp

Cả Java và C # đều làm điều này tương đối tầm thường. Tôi sẽ không ngạc nhiên nếu C ++ có cách tạo ra một trình vòng lặp ưa thích để bỏ qua các yếu tố nhất định không áp dụng. Nhưng đây chỉ thực sự là một lựa chọn nếu ngôn ngữ bạn chọn hỗ trợ và lý do bạn đang sử dụng breaklà vì có những điều kiện về việc bạn có xử lý một yếu tố hay không.

Mặt khác, có một lý do rất chính đáng để biến điều kiện của bạn thành một phần của vòng lặp for - giả sử đánh giá ban đầu của nó là chính xác.

• Dễ thấy hơn khi vòng lặp kết thúc sớm

Tôi đã làm việc với mã trong đó vòng lặp for của bạn mất vài trăm dòng với một số điều kiện và một số phép toán phức tạp đang diễn ra ở đó. Các vấn đề bạn gặp phải với điều này là:

• break Các lệnh được chôn trong logic rất khó tìm và đôi khi gây ngạc nhiên
• Gỡ lỗi đòi hỏi phải bước qua từng vòng lặp để thực sự hiểu những gì đang diễn ra
• Rất nhiều mã không có các phép tái cấu trúc có thể đảo ngược dễ dàng có sẵn hoặc các bài kiểm tra đơn vị để giúp tương đương về chức năng sau khi viết lại

Trong tình huống đó, tôi đề xuất các hướng dẫn sau theo thứ tự ưu tiên:

• Lọc bộ sưu tập để loại bỏ sự cần thiết breaknếu có thể
• Tạo phần có điều kiện của các điều kiện vòng lặp for
• Đặt các điều kiện có breakở đầu vòng lặp nếu có thể
• Thêm một chú thích vẽ nhiều dòng chú ý đến sự phá vỡ, và tại sao nó ở đó

Các nguyên tắc này luôn tuân theo tính chính xác của mã của bạn. Chọn tùy chọn có thể thể hiện tốt nhất ý định và cải thiện sự rõ ràng của mã của bạn.

Tôi thực sự khuyên bạn nên thực hiện phương pháp ít bất ngờ nhất trừ khi bạn đạt được một lợi ích đáng kể khi làm khác.

Mọi người không đọc từng chữ cái khi đọc một từ và họ không đọc từng chữ khi đọc một cuốn sách - nếu họ giỏi đọc, họ nhìn vào các phác thảo của các từ và câu và để cho bộ não của họ lấp đầy phần còn lại .

Vì vậy, rất có thể nhà phát triển thỉnh thoảng sẽ cho rằng đây chỉ là một tiêu chuẩn cho vòng lặp và thậm chí không nhìn vào nó:

for(int i=0;i<array.length&&!condition;i++)

Nếu bạn muốn sử dụng phong cách đó bất kể, tôi khuyên bạn nên thay đổi các bộ phận for(int i=0;i<và ;i++)nói với bộ não của người đọc rằng đây là một tiêu chuẩn cho vòng lặp.

Một lý do khác để đi cùng if- breaklà bạn không thể luôn luôn sử dụng phương pháp của mình với forđiều kiện. Bạn phải sử dụng if- breakkhi điều kiện ngắt quá phức tạp để ẩn trong forcâu lệnh hoặc dựa vào các biến chỉ có thể truy cập bên trong forvòng lặp.

for(int i=0;i<array.length&&!((someWidth.X==17 && y < someWidth.x/2) || (y == someWidth.x/2 && someWidth.x == 18);i++)

Vì vậy, nếu bạn quyết định đi cùng if- break, bạn được bảo vệ. Nhưng nếu bạn quyết định đi theo for-conditions, bạn phải sử dụng kết hợp if- breakvà for-conditions. Để thống nhất, bạn sẽ phải di chuyển các điều kiện qua lại giữa các forđiều kiện và if- breakbất cứ khi nào điều kiện thay đổi.

Chuyển đổi của bạn đang giả định rằng bất cứ điều gì conditionđược ước truetính khi bạn vào vòng lặp. Chúng tôi không thể nhận xét về tính chính xác của điều đó trong trường hợp này vì nó không được xác định.

Đã thành công trong việc "giảm dòng mã" ở đây, sau đó bạn có thể tiếp tục xem xét

for(int i=0;i<array.length;i++){
    // some other code
    if(condition){
        break;
    }
    // further code
}

và áp dụng chuyển đổi tương tự, đến

for(int i=0;i<array.length && !condition;i++){
    // some other code
    // further code
}

Đó là một chuyển đổi không hợp lệ, như bây giờ bạn vô điều kiện làm further codenơi mà trước đây bạn không làm.

Một sơ đồ chuyển đổi an toàn hơn nhiều là trích xuất some other codevà đánh giá conditionthành một hàm riêng biệt

bool evaluate_condition(int i) // This is an horrible name, but I have no context to improve it
{
     // some other code
     return condition;
}

for(int i=0;i<array.length && !evaluate_condition(i);i++){
    // further code
}

TL; DR Làm bất cứ điều gì đọc tốt nhất trong hoàn cảnh cụ thể của bạn

Hãy lấy ví dụ này:

for ( int i = 1; i < array.length; i++ ) 
{
    if(something) break;
    // perform operations
}

Trong trường hợp này, chúng tôi không muốn bất kỳ mã nào trong vòng lặp for thực thi nếu somethinglà đúng, do đó, việc di chuyển kiểm tra somethingvào trường điều kiện là hợp lý.

for ( int i = 1; i < array.length && !something; i++ )

Sau đó, một lần nữa, tùy thuộc vào việc somethingcó thể được đặt thành truetrước vòng lặp hay không, nhưng điều này có thể mang lại sự rõ ràng hơn:

if(!something)
{
    for ( int i = 1; i < array.length; i++ )
    {...}
}

Bây giờ hãy tưởng tượng điều này:

for ( int i = 1; i < array.length; i++ ) 
{
    // perform operations
    if(something) break;
    // perform more operations
}

Chúng tôi đang gửi một thông điệp rất rõ ràng ở đó. Nếu somethingtrở thành đúng trong khi xử lý mảng thì từ bỏ toàn bộ thao tác tại thời điểm này. Để di chuyển kiểm tra vào trường điều kiện bạn cần làm:

for ( int i = 1; i < array.length && !something; i++ ) 
{
    // perform operations
    if(!something)
    {
        // perform more operations
    }
}

Có thể cho rằng, "thông điệp" đã trở nên lầy lội và chúng tôi đang kiểm tra tình trạng lỗi ở hai nơi - điều gì xảy ra nếu điều kiện thất bại thay đổi và chúng ta quên một trong những nơi đó?

Tất nhiên có nhiều hình dạng khác nhau hơn cho một vòng lặp và điều kiện có thể, tất cả đều mang sắc thái riêng.

Viết mã để nó đọc tốt (điều này rõ ràng là hơi chủ quan) và chính xác. Bên ngoài một bộ hướng dẫn mã hóa hà khắc, tất cả các "quy tắc" đều có ngoại lệ. Viết những gì bạn cảm thấy thể hiện quyết định tốt nhất và giảm thiểu cơ hội cho những sai lầm trong tương lai.

Mặc dù nó có thể hấp dẫn bởi vì bạn thấy tất cả các điều kiện trong tiêu đề vòng lặp và breakcó thể gây nhầm lẫn bên trong các khối lớn, forvòng lặp là một mẫu mà hầu hết các lập trình viên mong đợi lặp trong phạm vi nào đó.

Đặc biệt là khi bạn làm như vậy, việc thêm một điều kiện phá vỡ bổ sung có thể gây nhầm lẫn và khó xem liệu nó có tương đương về mặt chức năng hay không.

Thường là một lựa chọn tốt là sử dụng một whilehoặc do {} whilevòng lặp mà kiểm tra cả hai điều kiện, giả sử mảng của bạn có ít nhất một phần tử.

int i=0
do {
    // some other code
    i++; 
} while(i < array.length && condition);

Sử dụng một vòng lặp chỉ kiểm tra một điều kiện và không chạy mã từ tiêu đề vòng lặp, bạn sẽ thấy rất rõ khi điều kiện được kiểm tra và điều kiện thực tế và mã nào có tác dụng phụ.

Điều này thật tệ, vì mã được đọc bởi con người - các forvòng lặp không thành ngữ thường khó hiểu, điều đó có nghĩa là các lỗi có nhiều khả năng được ẩn ở đây, nhưng mã gốc có thể đã được cải thiện trong khi giữ cả hai ngắn gọn và dễ đọc

Nếu điều bạn muốn là tìm một giá trị trong một mảng (mẫu mã được cung cấp có phần chung chung, nhưng cũng có thể là mẫu này), bạn chỉ có thể cố gắng sử dụng một hàm được cung cấp bởi ngôn ngữ lập trình dành riêng cho mục đích đó. Ví dụ: mã giả, vì ngôn ngữ lập trình không được chỉ định, các giải pháp thay đổi tùy theo ngôn ngữ cụ thể).

array.find(item -> item.valid)

Điều này đáng chú ý nên rút ngắn giải pháp trong khi đơn giản hóa nó vì mã của bạn nói cụ thể những gì bạn cần.

Vài lý do theo ý kiến ​​của tôi mà nói, bạn không nên.

1. Điều này làm giảm khả năng đọc.
   
2. Đầu ra có thể không giống nhau. Tuy nhiên, nó có thể được thực hiện với một do...whilevòng lặp (không while) vì điều kiện được kiểm tra sau khi thực thi mã.
   

Nhưng trên hết, hãy xem xét điều này,

for(int i=0;i<array.length;i++){

    // Some other code
    if(condition1){
        break;
    }

    // Some more code
    if(condition1){
        break;
    }

    // Some even more code
}

Bây giờ, bạn có thể thực sự đạt được nó bằng cách thêm các điều kiện này vào forđiều kiện đó không?

Tôi nghĩ loại bỏ breakcó thể là một ý tưởng tốt, nhưng không phải để lưu các dòng mã.

Ưu điểm của việc viết nó mà không có breakđiều kiện hậu của vòng lặp là rõ ràng và rõ ràng. Khi bạn hoàn thành vòng lặp và thực hiện dòng tiếp theo của chương trình, điều kiện vòng lặp của bạn i < array.length && !conditionphải là sai. Do đó, hoặc ilớn hơn hoặc bằng chiều dài mảng của bạn hoặc conditionlà đúng.

Trong phiên bản với break, có một gotcha ẩn. Điều kiện vòng lặp nói rằng vòng lặp chấm dứt khi bạn chạy một số mã khác cho từng chỉ số mảng hợp lệ, nhưng thực tế có một breakcâu lệnh có thể chấm dứt vòng lặp trước đó và bạn sẽ không thấy nó trừ khi bạn xem lại mã vòng lặp rất cẩn thận. Và các máy phân tích tĩnh tự động, bao gồm tối ưu hóa trình biên dịch, cũng có thể gặp khó khăn trong việc suy luận các điều kiện hậu của vòng lặp là gì.

Đây là lý do ban đầu Edgar Dijkstra đã viết về Goto được coi là có hại. Đây không phải là vấn đề về phong cách: thoát ra khỏi một vòng lặp khiến cho việc lập luận chính thức về tình trạng của chương trình trở nên khó khăn. Tôi đã viết rất nhiều break;báo cáo trong cuộc sống của mình, và một khi đã trưởng thành, tôi thậm chí đã viết một goto(để thoát ra khỏi nhiều cấp độ của vòng lặp bên trong quan trọng về hiệu suất và sau đó tiếp tục với một nhánh khác của cây tìm kiếm). Tuy nhiên, tôi có nhiều khả năng viết một returncâu lệnh có điều kiện từ một vòng lặp (không bao giờ chạy mã sau vòng lặp và do đó không thể làm hỏng các điều kiện hậu của nó) hơn a break.

Bản thảo

Trong thực tế, tái cấu trúc mã để đưa ra hành vi tương tự thực sự có thể cần nhiều dòng mã hơn. Tái cấu trúc của bạn có thể hợp lệ đối với một số mã khác hoặc nếu chúng tôi có thể chứng minh rằng điều đó conditionsẽ bắt đầu sai. Nhưng ví dụ của bạn là tương đương trong trường hợp chung với:

if ( array.length > 0 ) {
  // Some other code.
}
for ( int i = 1; i < array.length && !condition; i++ ) {
  // Some other code.
}

Nếu một số mã khác không phải là một lớp lót, thì bạn có thể chuyển nó sang một hàm để không lặp lại chính mình, và sau đó bạn gần như đã tái cấu trúc vòng lặp của mình thành một hàm đệ quy đuôi.

Tuy nhiên, tôi nhận ra đây không phải là điểm chính trong câu hỏi của bạn và bạn đã giữ nó đơn giản.

Có, nhưng cú pháp của bạn là độc đáo và do đó xấu (tm)

Hy vọng rằng ngôn ngữ của bạn hỗ trợ một cái gì đó như

while(condition) //condition being a condition which if true you want to continue looping
{
    do thing; //your conditionally executed code goes here
    i++; //you can use a counter if you want to reference array items in order of index
}

Nếu bạn lo lắng về một fortuyên bố quá phức tạp khó đọc, đó chắc chắn là một mối quan tâm hợp lệ. Lãng phí không gian dọc cũng là một vấn đề (mặc dù ít quan trọng hơn).

(Cá nhân tôi không thích các quy tắc mà ifbáo cáo phải luôn có niềng răng, trong đó phần lớn là nguyên nhân của không gian dọc lãng phí ở đây. Lưu ý rằng vấn đề là lãng phí không gian thẳng đứng. Sử dụng không gian thẳng đứng với dòng có ý nghĩa không phải là một vấn đề.)

Một lựa chọn là chia nó thành nhiều dòng. Đây chắc chắn là những gì bạn nên làm nếu bạn đang sử dụng các forcâu lệnh thực sự phức tạp , với nhiều biến và điều kiện. (Điều này đối với tôi là sử dụng tốt hơn không gian theo chiều dọc, đưa ra càng nhiều dòng càng tốt một cái gì đó có ý nghĩa.)

for (
   int i = 0, j = 0;
   i < array.length && !condition;
   i++, j++
) {
   // stuff
}

Một cách tiếp cận tốt hơn có thể là cố gắng sử dụng một hình thức khai báo và ít bắt buộc hơn. Điều này sẽ thay đổi tùy thuộc vào ngôn ngữ hoặc bạn có thể cần phải viết các chức năng của riêng mình để kích hoạt loại điều này. Nó cũng phụ thuộc vào những gì conditionthực sự là. Có lẽ nó phải có khả năng thay đổi bằng cách nào đó, tùy thuộc vào những gì trong mảng.

array
.takeWhile(condition)  // condition can be item => bool or (item, index) => bool
.forEach(doSomething); // doSomething can be item => void or (item, index) => void

Một điều đã bị lãng quên: Khi tôi thoát khỏi một vòng lặp (không thực hiện tất cả các lần lặp có thể, bất kể được triển khai như thế nào), đó thường là trường hợp không chỉ tôi muốn thoát khỏi vòng lặp, tôi cũng sẽ muốn biết tại sao điều này xảy ra . Ví dụ, nếu tôi tìm kiếm một mục X, tôi không chỉ thoát khỏi vòng lặp, tôi cũng muốn biết rằng X đã được tìm thấy và nó ở đâu.

Trong tình huống đó, có một điều kiện bên ngoài vòng lặp là khá tự nhiên. Vì vậy, tôi bắt đầu với

bool found = false;
size_t foundIndex;

và trong vòng lặp tôi sẽ viết

if (condition) {
    found = true;
    foundIndex = i;
    break;
}

với vòng lặp for

for (i = 0; i < something && ! found; ++i)

Bây giờ kiểm tra điều kiện trong vòng lặp là khá tự nhiên. Việc có câu lệnh "break" hay không phụ thuộc vào việc có xử lý thêm trong vòng lặp mà bạn muốn tránh hay không. Nếu một số xử lý là cần thiết và xử lý khác là không, bạn có thể có một cái gì đó như

if (! found) { ... }

một nơi nào đó trong vòng lặp của bạn.