Czy używanie przerwy w pętli for jest złą praktyką? [Zamknięte]

Czy używanie breakinstrukcji wewnątrz forpętli jest złą praktyką ?

Powiedz, szukam wartości w tablicy. Porównaj wewnątrz pętli for i gdy zostanie znaleziona wartość, break;aby wyjść z pętli for.

Czy to zła praktyka? Widziałem alternatywę używany: zdefiniować zmienną vFoundi ustawić go na true, gdy wartość jest znaleźć i sprawdzić vFoundw forwarunku instrukcji. Ale czy konieczne jest utworzenie nowej zmiennej tylko w tym celu?

Pytam w kontekście normalnej pętli for w C lub C ++.

PS: Wytyczne kodowania MISRA odradzają stosowanie przerwy.

Wiele odpowiedzi tutaj, ale jeszcze tego nie widziałem:

Większość „niebezpieczeństw” związanych z używaniem breaklub continuew pętli for jest negowana, jeśli piszesz uporządkowane, łatwe do odczytania pętle. Jeśli treść twojej pętli obejmuje kilka długości ekranu i ma wiele zagnieżdżonych podbloków, tak, możesz łatwo zapomnieć, że jakiś kod nie zostanie wykonany po przerwie. Jeśli jednak pętla jest krótka i trafna, cel instrukcji break powinien być oczywisty.

Jeśli pętla staje się zbyt duża, zamiast tego użyj jednego lub więcej dobrze nazwanych wywołań funkcji w pętli. Jedynym prawdziwym powodem, aby tego uniknąć, są wąskie gardła przetwarzania.

Nie, przerwa to właściwe rozwiązanie.

Dodanie zmiennej boolowskiej utrudnia czytanie kodu i dodaje potencjalne źródło błędów.

Możesz znaleźć wszelkiego rodzaju profesjonalny kod z instrukcjami „break”. Używanie tego w razie potrzeby ma sens. W twoim przypadku ta opcja jest lepsza niż tworzenie osobnej zmiennej tylko w celu wyjścia z pętli.

Używanie breakjak również continuew forpętli jest w porządku.

Upraszcza kod i poprawia jego czytelność.

Daleko od złej praktyki, Python (i inne języki?) Rozszerzył strukturę forpętli , tak że jej część zostanie wykonana tylko wtedy, gdy pętla tego nie zrobi break .

for n in range(5):
    for m in range(3):
        if m >= n:
            print('stop!')
            break
        print(m, end=' ')
    else:
        print('finished.')

Wynik:

stop!
0 stop!
0 1 stop!
0 1 2 finished.
0 1 2 finished.

Równoważny kod bez breaki to przydatne else:

for n in range(5):
    aborted = False
    for m in range(3):
        if not aborted:
            if m >= n:
                print('stop!')
                aborted = True
            else:            
                print(m, end=' ')
    if not aborted:
        print('finished.')

Nie ma nic złego w używaniu instrukcji break, ale zagnieżdżone pętle mogą być mylące. Aby poprawić czytelność, wiele języków ( przynajmniej Java ) obsługuje łamanie etykiet, co znacznie poprawi czytelność.

int[] iArray = new int[]{0,1,2,3,4,5,6,7,8,9};
int[] jArray = new int[]{0,1,2,3,4,5,6,7,8,9};

// label for i loop
iLoop: for (int i = 0; i < iArray.length; i++) {

    // label for j loop
    jLoop: for (int j = 0; j < jArray.length; j++) {

        if(iArray[i] < jArray[j]){
            // break i and j loops
            break iLoop;
        } else if (iArray[i] > jArray[j]){  
            // breaks only j loop
            break jLoop;
        } else {
            // unclear which loop is ending
            // (breaks only the j loop)
            break;
        }
    }
}

Powiem, że instrukcje break (and return) często zwiększają cykliczną złożoność, co utrudnia udowodnienie, że kod działa poprawnie we wszystkich przypadkach.

Jeśli rozważasz użycie przerwy podczas iteracji sekwencji dla określonego elementu, możesz ponownie rozważyć strukturę danych używaną do przechowywania danych. Używanie czegoś takiego jak zestaw lub mapa może zapewnić lepsze wyniki.

break jest całkowicie akceptowalnym poleceniem do użycia (tak samo jest continue , btw). Chodzi o czytelność kodu - o ile nie masz zbyt skomplikowanych pętli i tym podobnych, wszystko jest w porządku.

To nie tak, że byli w tej samej lidze co goto . :)

Zasada ogólna: jeśli przestrzeganie zasady wymaga zrobienia czegoś bardziej niezręcznego i trudnego do przeczytania, a następnie złamania reguły, należy ją złamać.

W przypadku zapętlania się, dopóki czegoś nie znajdziesz, napotkasz problem rozróżnienia znalezionego i nie znalezionego, gdy wyjdziesz. To jest:

for (int x=0;x<fooCount;++x)
{
  Foo foo=getFooSomehow(x);
  if (foo.bar==42)
    break;
}
// So when we get here, did we find one, or did we fall out the bottom?

Więc w porządku, możesz ustawić flagę lub zainicjować wartość „znalezioną” na null. Ale

Dlatego generalnie wolę przekierowywać moje wyszukiwania do funkcji:

Foo findFoo(int wantBar)
{
  for (int x=0;x<fooCount;++x)
  {
    Foo foo=getFooSomehow(x);
    if (foo.bar==wantBar)
      return foo;
  }
  // Not found
  return null;
}

Pomaga to również uporządkować kod. W głównym wierszu „znajdź” staje się pojedynczą instrukcją, a gdy warunki są złożone, są zapisywane tylko raz.

To zależy od języka. Chociaż możesz tutaj sprawdzić zmienną boolowską:

for (int i = 0; i < 100 && stayInLoop; i++) { ... }

nie można tego zrobić podczas iterowania po tablicy:

for element in bigList: ...

W każdym razie breaksprawiłoby, że oba kody byłyby bardziej czytelne.

W twoim przykładzie nie znasz liczby iteracji pętli for . Dlaczego nie używać while pętli zamiast, który pozwala liczba iteracji być nieokreślona na początku?

Nie jest zatem konieczne stosowanie przerwy statemement w ogóle, jak pętla może być lepiej zaznaczono jako while pętli.

Zgadzam się z innymi, którzy zalecają używanie break. Oczywiste pytanie brzmi: dlaczego ktoś miałby zalecać inaczej? Cóż ... kiedy używasz break, pomijasz resztę kodu w bloku i pozostałe iteracje. Czasami powoduje to błędy, na przykład:

• zasób uzyskany na górze bloku może zostać zwolniony na dole (jest to prawdą nawet dla bloków wewnątrz forpętli), ale ten krok zwolnienia może zostać przypadkowo pominięty, gdy „przedwczesne” wyjście jest spowodowane breakinstrukcją (w „nowoczesnym” C ++, „RAII” jest używany do obsługi tego w niezawodny i bezpieczny sposób: w zasadzie destruktory obiektów niezawodnie zwalniają zasoby bez względu na sposób zamykania zakresu)

• ktoś może zmienić test warunkowy w forinstrukcji, nie zauważając, że istnieją inne zdelokalizowane warunki wyjścia

• Odpowiedź ndim wskazuje, że niektórzy ludzie mogą unikać breaks, aby utrzymać względnie spójny czas wykonywania pętli, ale porównujesz breakz użyciem boolowskiej zmiennej kontrolnej wczesnego wyjścia, gdzie to się nie sprawdza

Od czasu do czasu ludzie obserwujący takie błędy zdają sobie sprawę, że można im zapobiec / złagodzić tę zasadę „bez przerw”… rzeczywiście, istnieje cała powiązana strategia „bezpieczniejszego” programowania zwanego „programowaniem strukturalnym”, gdzie każda funkcja powinna mieć pojedynczy punkt wejścia i wyjścia (tj. brak goto, brak wcześniejszego powrotu). Może wyeliminować niektóre błędy, ale niewątpliwie wprowadza inne. Dlaczego oni to robią?

• mają strukturę programistyczną, która zachęca do określonego stylu programowania / kodu i mają dowody statystyczne, że daje to korzyści netto w tej ograniczonej strukturze, lub
• byli pod wpływem wytycznych programowania lub doświadczenia w takich ramach, lub
• są po prostu dyktatorskimi idiotami, albo
• dowolna z powyższych + bezwładność historyczna (istotna, ponieważ uzasadnienia mają większe zastosowanie do C niż współczesnego C ++).

Jest całkowicie ważny w użyciu break- jak zauważyli inni, nigdzie nie jest w tej samej lidze co goto.

Chociaż możesz chcieć użyć vFoundzmiennej, gdy chcesz sprawdzić poza pętlą, czy wartość została znaleziona w tablicy. Również z punktu widzenia łatwości konserwacji, posiadanie wspólnej flagi sygnalizującej kryteria wyjścia może być przydatne.

Dokonałem analizy kodu źródłowego, nad którym obecnie pracuję (40 000 linii JavaScript).

Znalazłem tylko 22 breakstwierdzenia, z których:

• 19 zostało użytych w switchinstrukcjach (w sumie mamy tylko 3 instrukcje switch!).
• 2 były używane wewnątrz forpętli - kod, który od razu sklasyfikowałem jako do ponownego przekształcenia w osobne funkcje i zastąpiony returninstrukcją.
• A jeśli chodzi o ostatnią pętlę breakwewnętrzną while... Pobiegłem, git blameżeby zobaczyć, kto napisał to gówno!

Więc według moich statystyk: jeśli breakjest używany na zewnątrz switch, jest to zapach kodu.

Szukałem też continuewypowiedzi. Nie znaleziono.

Nie widzę żadnego powodu, dla którego byłaby to zła praktyka POD WZGLĘDEM, że chcesz zakończyć przetwarzanie w tym momencie.

W świecie osadzonych jest dużo kodu, który wykorzystuje następującą konstrukcję:

    while(1)
    { 
         if (RCIF)
           gx();
         if (command_received == command_we_are_waiting_on)
           break;
         else if ((num_attempts > MAX_ATTEMPTS) || (TickGet() - BaseTick > MAX_TIMEOUT))
           return ERROR;
         num_attempts++;
    }
    if (call_some_bool_returning_function())
      return TRUE;
    else
      return FALSE;

To bardzo ogólny przykład, wiele rzeczy dzieje się za kurtyną, w szczególności przerw. Nie używaj tego jako standardowego kodu, po prostu próbuję zilustrować przykład.

Osobiście uważam, że nie ma nic złego w pisaniu pętli w ten sposób, o ile zostanie podjęta odpowiednia uwaga, aby nie pozostawać w pętli w nieskończoność.

Zależy od twojego przypadku użycia. Istnieją aplikacje, w których czas wykonywania pętli for musi być stały (np. W celu spełnienia pewnych ograniczeń czasowych lub ukrycia wewnętrznych danych przed atakami opartymi na czasie).

W takich przypadkach ma sens nawet ustawienie flagi i sprawdzanie wartości flagi tylko PO wykonaniu wszystkich foriteracji pętli. Oczywiście wszystkie iteracje pętli for muszą uruchamiać kod, który nadal zajmuje mniej więcej tyle samo czasu.

Jeśli nie zależy Ci na czasie wykonywania ... użyj break;i, continue;aby kod był łatwiejszy do odczytania.

Na regułach MISRA 98, które są używane w mojej firmie w C dev, instrukcja break nie powinna być używana ...

Edycja: przerwa jest dozwolona w MISRA '04

Oczywiście break;rozwiązaniem jest zatrzymywanie pętli for lub foreach. Użyłem go w php w pętli foreach i for i stwierdziłem, że działa.

Nie zgadzam się!

Dlaczego miałbyś ignorować wbudowaną funkcjonalność pętli for, aby stworzyć własną? Nie musisz wymyślać koła na nowo.

Myślę, że bardziej sensowne jest umieszczanie czeków na górze pętli for

for(int i = 0; i < myCollection.Length && myCollection[i].SomeValue != "Break Condition"; i++)
{
//loop body
}

lub jeśli najpierw musisz przetworzyć wiersz

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
//loop body
}

W ten sposób możesz napisać funkcję, która wykona wszystko i stworzy znacznie bardziej przejrzysty kod.

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

Lub jeśli twój stan jest skomplikowany, możesz też przenieść ten kod!

for(int i = 0; i < myCollection.Length && BreakFunctionCheck(i, myCollection); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

„Kod Profesjonalny”, pełen przerw, nie brzmi dla mnie jak kod profesjonalny. Brzmi jak leniwe kodowanie;)