developer tip

JavaScript에서 "continue"문이 잘못된 이유는 무엇입니까?

copycodes 2020. 11. 28. 09:40
반응형

JavaScript에서 "continue"문이 잘못된 이유는 무엇입니까?


Javascript : The Good Parts by Douglas Crockford 에서 저자는 continue Statement에 대해 다음과 같이 말합니다.

continue문은 루프의 맨 위로 이동합니다. 나는 continue문장 을 제거하기 위해 리팩토링함으로써 개선되지 않은 코드를 본 적이 없다 .

이것은 정말 나를 혼란스럽게합니다. 나는 Crockford가 JavaScript에 대해 매우 독단적 인 견해를 가지고 있다는 것을 알고 있지만 이것은 완전히 잘못된 것 같습니다.

우선 continue, 루프의 맨 위로 점프하는 것 이상을 수행합니다. 기본적으로 다음 반복으로도 진행됩니다. 그래서 Crockford의 진술은 완전히 잘못된 정보가 아닙니까?

더 중요한 것은 왜 continue나쁘다고 여겨지 는지 완전히 이해하지 못한다 는 것입니다. 이 게시물은 일반적인 가정 인 것처럼 보이는 것을 제공합니다 . 루프 내부에서 계속하는 것이 왜 나쁜 생각입니까?

continue특정 인스턴스에서 코드를 읽기 어렵게 만드는 방법을 이해하지만 코드를 더 읽기 쉽게 만들 수 있다고 생각합니다. 예를 들면 :

var someArray=['blah',5,'stuff',7];
for(var i=0;i<someArray.length;i++){
    if(typeof someArray[i]==='number'){
        for(var j=0;j<someArray[i];j++){
            console.log(j);
        }
    }
}

이것은 다음과 같이 리팩토링 될 수 있습니다.

var someArray=['blah',5,'stuff',7];
for(var i=0;i<someArray.length;i++){
    if(typeof someArray[i]!=='number'){
        continue;
    }
    for(var j=0;j<someArray[i];j++){
        console.log(j);
    }
}

continue이 특정 예제에서 특히 유용하지는 않지만 중첩 깊이를 감소 시킨다는 사실을 보여줍니다. 더 복잡한 코드에서는 잠재적으로 가독성을 높일 수 있습니다.

Crockford는 왜 continue사용하지 말아야 하는지에 대한 설명을 제공하지 않습니다. 그래서 제가 놓치고있는이 의견 뒤에 더 깊은 의미가 있습니까?


그 진술은 말도 안됩니다. continue남용 될 수 있지만 종종 가독성에 도움이됩니다 .

일반적인 사용 :

for (somecondition)
{
    if (!firsttest) continue;

    some_provisional_work_that_is_almost_always_needed();

    if (!further_tests()) continue;

    do_expensive_operation();
}

목표는 깊이 중첩 된 조건이있는 'lasagna'코드를 피하는 것입니다.

추가하기 위해 편집 :

예, 이것은 궁극적으로 주관적입니다. 결정을위한 측정 기준은 다음과 같습니다.

마지막으로 한 번 수정 :

물론이 예제는 너무 간단하며 항상 중첩 된 조건을 함수 호출로 바꿀 수 있습니다. 그러나 그런 다음 참조를 통해 중첩 된 함수에 데이터를 전달해야 할 수 있으며, 이로 인해 최소한 피하려는 문제만큼 나쁜 리팩토링 문제가 발생할 수 있습니다.


나는 개인적으로 여기서 대다수와는 다른 편이다. 문제는 일반적으로 표시된 continue패턴이 아니라 가능한 코드 경로를 확인하기 어려울 수있는 더 깊게 중첩 된 패턴에 있습니다.

그러나 당신의 예조차도 continue정당한 내 의견의 개선을 보여주지 않습니다. 내 경험상 몇 가지 continue진술은 나중에 리팩토링 하기에는 악몽입니다 (특히 누군가 나중에 거기에 넣을 때 Java와 같은 자동 리팩토링에 더 적합한 정적 언어의 경우 break에도).

따라서 나는 당신이 준 인용문에 주석을 추가 할 것입니다.

continue을 제거 하기위한 리팩토링은 리팩토링 할 수있는 추가 능력을 향상시킵니다.

그리고 내부 루프는 예를 들어 함수를 추출 하기에 정말 좋은 후보입니다 . 이러한 리팩토링은 내부 루프가 복잡 해져서 continue고통 스러울 때 수행됩니다 .

These are my honest opinions after working professionally on JavaScript projects in a team, there rules that Douglas Crockford talks about really show their merits.


Douglas Crockford may feel this way because he doesn't believe in assignment within a conditional. In fact, his program JSlint doesn't even let you do it, even though Javascript does. He would never write:

Example 1

while (rec = getrec())
{   
    if (condition1(rec))
        continue;

    doSomething(rec);
}

but, I'm guessing he would write something like:

Example 2

rec = getrec();

while (rec)
{   
    if (!condition(rec))
        doSomething(rec);

    rec = getrec();
}

Both of these work, but if you accidentally mix these styles you get an infinite loop:

Example 3

rec = getrec();

while (rec)
{   
    if (condition1(rec))
        continue;

    rec = getrec();
}

This could be part of why he doesn't like continues.


Continue is an extremely useful tool for saving computation cycles in algorithms. Sure, it can be improperly used but so can every other keyword or approach. When striving for performance, it can be useful to take an inverse approach to path divergence with a conditional statement. A continue can facilitate the inverse by allowing less efficient paths to be skipped when possible.


Actually, from all the analysis it seems:

  1. If you have shallow loops - feel free to use continue iff it improves readability (also, there may be some performance gains?).
  2. If you have deep nested loops (which means you already have a hairball to untangle when you re-factor) avoiding continue may prove to be beneficial from a code reliability standpoint.

In defense of Douglas Crokford, I feel that his recommendations tend to lean towards defensive programming, which, in all honesty seems like a good approach for 'idiot-proofing' the code in the enterprise.


Personally, I have never heard anything bad about using the continue statement. It is true that it could (most of the time) be easily avoided, but there is no reason to not use it. I find that loops can be a lot cleaner looking and more readable with continue statements in place.

참고URL : https://stackoverflow.com/questions/11728757/why-are-continue-statements-bad-in-javascript

반응형