문제

개발자는 사용을 피해야합니까? 계속하다 루프의 다음 반복을 강제하기 위해 C# 또는 다른 언어의 이에 상응하는 기능을 사용합니까?찬성 또는 반대 주장이 다음 주장과 중복됩니까? 이동?

도움이 되었습니까?

해결책

계속 사용하는 것이 더 많아져야 한다고 생각합니다!

다음과 같은 코드를 너무 자주 접하게 됩니다.

for (...)
{
   if (!cond1)
   {
      if (!cond2)
      {
          ... highly indented lines ...
      }
   }
}

대신에

for (...)
{
   if (cond1 || cond2)
   {
      continue;
   }

   ...
}

코드를 더 읽기 쉽게 만드는 데 사용하세요!

다른 팁

~이다 continue 이보다 더 해로운 것은 break?

어쨌든 내가 이 코드를 접하거나 사용하는 대부분의 경우 코드가 더 명확해지고 스파게티 느낌이 덜하다는 것을 알았습니다.

계속을 사용하거나 사용하지 않고 좋은 코드를 작성할 수 있고, 계속을 사용하거나 사용하지 않고 잘못된 코드를 작성할 수 있습니다.

아마도 goto에 대한 인수와 일부 중복되는 부분이 있을 수 있지만 제가 생각하는 한 continue 사용은 메서드 본문의 어디에서나 break 문(루프 내) 또는 return 문을 사용하는 것과 동일합니다. 올바르게 사용하면 코드를 단순화할 수 있습니다. (버그가 포함될 가능성이 적고 유지 관리가 더 쉽습니다)

유해한 키워드가 없습니다.오직 해로운 용도만 있을 뿐입니다.

Goto는 그 자체로 해롭지 않으며 계속하지도 않습니다.조심스럽게 사용해야합니다. 그게 전부입니다.

계속 진행으로 인해 가독성 문제가 발생한다면 다른 문제가 있을 가능성이 있습니다.예를 들어 for 루프 내부에는 엄청난 양의 코드가 있습니다.큰 for 루프를 작성해야 한다면 for 루프의 상단에 가까운 continue를 사용하려고 노력할 것입니다.그렇지 않으면 for 루프 중간에 깊이 묻혀 있는 연속을 쉽게 놓칠 수 있습니다.

나는 간단한 if 조건을 처리하기 위해 루프 시작 부분에 계속을 사용하는 것을 좋아합니다.

나에게는 추가 중첩이 없기 때문에 코드를 더 읽기 쉽게 만들고 이러한 경우를 명시적으로 처리했다는 것을 알 수 있습니다.

이것이 내가 goto를 사용하는 것과 같은 이유입니까?아마도.때때로 가독성을 높이고 코드 중첩을 중지하기 위해 사용하지만 일반적으로 정리/오류 처리에 더 많이 사용합니다.

나는 말할 것입니다 :"때에 따라 다르지".

합리적으로 작은 루프 코드(스크롤하지 않고 전체 루프 코드를 볼 수 있는 경우)가 있는 경우 일반적으로 계속을 사용해도 괜찮습니다.

그러나 루프 본문이 크고(예를 들어 큰 스위치로 인해) 후속 코드가 있는 경우(예: 스위치 아래) 계속을 추가하고 때때로 해당 코드를 건너뛰어 버그를 쉽게 도입할 수 있습니다.바이트코드 인터프리터의 핵심에서 이 문제를 발견했습니다. 일부 계측 코드는 일부 경우 분기의 ​​계속으로 인해 실행되지 않는 경우가 있었습니다.

이는 다소 인위적으로 구성된 경우일 수 있지만 일반적으로 계속을 피하고 if를 사용하려고 합니다(그러나 Rob의 샘플 코드에서처럼 너무 깊게 중첩되지는 않음).

계속 진행하는 것이 코드 블록 밖으로 실행을 이동하지 않기 때문에 계속 진행하는 것이 goto만큼 어려울 수는 없다고 생각합니다.

어떤 종류의 결과 집합을 반복하고 해당 결과에 대해 작업을 수행하는 경우(예: 각각에 대해) 특정 결과로 인해 문제가 발생한 경우 예상되는 오류를 캡처하는 데 다소 유용합니다(try-catch를 통해). 이를 기록하고 계속을 통해 다음 결과로 넘어갑니다.계속은 이상한 시간에 작업을 수행하는 무인 서비스에 특히 유용하며 한 가지 예외가 다른 x개의 레코드에 영향을 주어서는 안 됩니다.

  1. 불필요한 요소에 대한 반복을 피하기 위해 루프 시작 부분에 continue를 사용하는 것은 해롭지 않고 매우 유용할 수 있지만 중첩된 if 및 else 중간에 이를 사용하면 루프 코드를 이해하고 검증하기 위해 복잡한 미로로 바꿀 수 있습니다.

  2. 나는 그 사용을 회피하는 것도 의미론적 오해의 결과라고 생각한다.코드에서 'continue' 키워드를 보거나 쓰지 않는 사람들은 continue가 포함된 코드를 보면 이를 "자연스러운 흐름의 연속"으로 해석할 수 있습니다.계속하는 대신에 우리는 다음, 예를 들어, 더 많은 사람들이 이 귀중한 커서 기능을 높이 평가할 것이라고 생각합니다.

goto는 계속으로 사용할 수 있지만 그 반대는 사용할 수 없습니다.

어디든 "이동"할 수 있으므로 흐름 제어를 임의로 중단할 수 있습니다.

따라서 계속하면 거의 해롭지 않습니다.

다른 사람들이 힌트를 줬는데...그러나 계속 및 중단은 다음에 의해 시행됩니다. 컴파일러 고유한 관련 규칙이 있습니다.Goto에는 그러한 제한이 없습니다. ~할 것 같다 어떤 상황에서는 거의 동일합니다.

나는 계속하거나 중단하는 것이 그 자체로 해롭다고 생각하지 않습니다. 하지만 어느 쪽이든 제정신의 프로그래머가 개그를 하는 방식으로 잘못 사용될 수 있다고 확신합니다.

나는 그렇다고 말하고 싶습니다.나에게 그것은 유동적으로 작성된 코드 조각의 '흐름'을 깨뜨릴 뿐입니다.

또 다른 주장은 대부분의 현대 언어에서 지원하는 기본 키워드를 고수한다면 프로그램 흐름(로직이나 코드가 아닌 경우)을 다른 언어로 이식할 수 있다는 것입니다.지원되지 않는 키워드(예: continue 또는 goto)가 있으면 문제가 발생합니다.

개인적으로 선호하는 방식에 가깝지만 한 번도 사용할 필요가 없었고 새 코드를 작성할 때 실제로 옵션으로 고려하지도 않았습니다.(goto와 동일합니다.)

이 프로그래머에 관한 한, 중첩된 if/else 유해한 것으로 간주됩니다.

계속은 특정 조건에서 코드 블록을 건너뛸 수 있게 해주기 때문에 대부분의 언어에서 정말 유용한 기능입니다.

한 가지 대안은 if 문에서 부울 변수를 사용하는 것이지만, 사용할 때마다 재설정해야 합니다.

계속 나에게 잘못된 느낌이 듭니다.휴식을 취하면 거기에서 벗어날 수 있지만 계속하면 스파게티처럼 보입니다.

반면에 break를 사용하여 계속을 에뮬레이트할 수 있습니다(적어도 Java에서는).

for (String str : strs) contLp: {
    ...
       continue contLp;
    ...
}

continue는 어떤 상황에서는 유용할 수 있지만 여전히 나에게는 지저분하게 느껴집니다.

for (char c : cs) {
    final int i;
    if ('0' <= c && c <= '9') {
        i = c - '0';
    } else if ('a' <= c && c <= 'z') {
        i = c - 'a' + 10;
    } else {
        continue;
    }
    ... use i ...
}

나는 계속에 대한 결론적 주장은 코드가 정확하다는 것을 증명하기가 더 어렵다는 것이라고 믿습니다.이것은 수학적 의미에서 증명됩니다.그러나 상당히 복잡한 컴퓨터 프로그램을 '증명'할 자원이 아무도 없기 때문에 그것은 아마도 당신에게 중요하지 않을 것입니다.

정적 분석 도구를 입력하십시오.당신은 그 사람들을 더 힘들게 할 수도 있습니다...

그리고 goto는 같은 이유로 악몽처럼 들리지만 코드의 임의 위치에 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top