레이블이 지정된 루프를 리팩토링하여 제거

https://stackoverflow.com/questions/15851

08-06-2019
|

문제

표시된 중단/계속이 완전히 "nono"라고 확신한 후 여기, 내 코드에서 레이블을 제거하는 데 도움이 필요합니다.

정사각형 행렬과 길이가 같은 벡터가 있습니다.벡터에는 이미 일부 값이 있으며 행렬의 값에 따라 벡터가 루프에서 변경됩니다.

코드 조각이 기본적으로 이해할 수 있기를 바랍니다.

vectorLoop:
for( int idx = 0; idx < vectorLength; idx++) {
    if( conditionAtVectorPosition( v, idx ) ) continue vectorLoop;

    matrixLoop:
    for( rowIdx = 0; rowIdx < n; rowIdx++ ) {
        if( anotherConditionAtVector( v, rowIdx ) ) continue matrixLoop;
        if( conditionAtMatrixRowCol( m, rowIdx, idx ) ) continue vectorLoop;
    }
    setValueInVector( v, idx );
}

라벨이 없는 더 읽기 쉽고 더 나은 버전이 있다는 것을 저에게 설득해 주세요.

해결책

지금까지 제시된 솔루션을 살펴보면 다음과 같습니다.

알고리즘 자체보다는 코드 메커니즘에 더 많은 코드를 소비한다는 점에서 모두 원본보다 가독성이 떨어지는 것처럼 보입니다.
그 중 일부는 깨졌거나 편집되기 전의 내용이었습니다.가장 끔찍한 것은 사람들이 라벨 없이 코드를 작성하고 어떤 것도 깨지지 않는 방법에 대해 매우 열심히 생각해야 한다는 사실입니다.
일부에서는 동일한 테스트를 두 번 실행하면 성능이 저하되는데, 이는 항상 사소한 것은 아닙니다.이에 대한 대안은 부울 값을 저장하고 전달하는 것인데, 이는 추악합니다.
코드의 관련 부분을 메소드로 리팩토링하는 것은 사실상 아무 작업도 하지 않습니다.코드가 파일에 배치되는 방식을 재정렬하지만 실행 방식에는 영향을 미치지 않습니다.

이 모든 사실은 적어도 이 질문의 경우에는 레이블이 올바른 솔루션이며 리팩토링할 필요가 없다고 믿게 만듭니다.확실히 레이블이 잘못 사용되어 리팩터링되어야 하는 경우가 있습니다.나는 그것이 깨지지 않는 규칙으로 취급되어야 한다고 생각하지 않습니다.

다른 팁

@Patrick 당신은 setValueInVector( v, idx );두 번째 루프가 끝나면 괜찮습니다.코드가 동일하려면 논리적으로 다음과 같이 다시 작성해야 합니다.

for( int idx = 0; idx

쉽게, 나의 좋은 사람.

for( int idx = 0; idx < vectorLength; idx++) {
  if( conditionAtVectorPosition( v, idx ) ) continue;

  for( rowIdx = 0; rowIdx < n; rowIdx++ ) {
    if( anotherConditionAtVector( v, rowIdx ) ) continue;
    if( conditionAtMatrixRowCol( m, rowIdx, idx ) ) break;
  }
  if( !conditionAtMatrixRowCol( m, rowIdx, idx ) )
    setValueInVector( v, idx );
}

편집하다:맞습니다. 당신은 앤더스입니다.이를 고려하여 솔루션을 편집했습니다.

코드를 읽음으로써.

ConditionAtVectorPosition에서 잘못된 벡터 위치를 제거한 다음 anotherConditionAtVector에서 잘못된 행을 제거한 것으로 나타났습니다.
idx의 값이 무엇이든 anotherConditionAtVector는 행 인덱스에만 의존하기 때문에 anotherConditionAtVector에서 행을 확인하는 것은 중복되는 것 같습니다( anotherConditionAtVector에 부작용이 없다고 가정).

그래서 당신은 이것을 할 수 있습니다 :

먼저 ConditionAtVectorPosition을 사용하여 유효한 위치를 가져옵니다(유효한 열임).
그런 다음 anotherConditionAtVector를 사용하여 유효한 행을 가져옵니다.
마지막으로 유효한 열과 행을 사용하여 ConditionAtMatrixRowCol을 사용합니다.

이게 도움이 되길 바란다.

@니콜라스

그 중 일부는 깨졌거나 편집되기 전의 내용이었습니다.가장 큰 것은 사람들이 레이블없이 코드를 작성하는 방법에 대해 열심히 생각하고 아무것도 깨지지 않는다는 사실입니다.

나는 다른 관점을 가지고 있습니다:그들 중 일부는 원래 알고리즘의 동작을 파악하기가 어렵 기 때문에 깨졌습니다.

주관적이라는 점은 알지만 원래 알고리즘을 읽는 데에는 아무런 문제가 없습니다.제안된 대체품보다 더 짧고 명확합니다.

이 스레드의 모든 리팩토링은 다른 언어 기능을 사용하여 레이블의 동작을 에뮬레이트하는 것입니다. 마치 레이블이 없는 언어로 코드를 이식하는 것처럼 말입니다.

일부에서는 동일한 테스트를 두 번 실행하면 성능이 저하되는데, 이는 항상 사소한 것은 아닙니다.이에 대한 대안은 부울 값을 저장하고 전달하는 것인데, 이는 추악합니다.
성능 저하가 미미합니다.그러나 테스트를 두 번 실행하는 것은 좋은 해결책이 아니라는 데 동의합니다.

문제는 알고리즘을 최적화하는 방법이 아니라 레이블을 제거하는 방법이라고 생각합니다.원래 포스터는 라벨 없이 '계속' 및 '중단' 키워드를 사용하는 방법을 인식하지 못하는 것처럼 보였지만 물론 내 가정이 틀렸을 수도 있습니다.

성능에 관해서는 게시물에서 다른 기능의 구현에 대한 정보를 제공하지 않으므로 컴파일러에서 인라인된 간단한 계산으로 구성된 FTP를 통해 결과를 다운로드하는 것이 나을 수도 있다는 것을 알고 있습니다.

즉, 동일한 테스트를 두 번 수행하는 것은 이론적으로 최적이 아닙니다.

편집하다:다시 생각해 보면 이 예는 실제로 레이블을 끔찍하게 사용하는 것이 아닙니다.나는 동의한다 "goto는 안돼요", 하지만 이와 같은 코드 때문은 아닙니다.여기서 레이블을 사용하는 것은 실제로 코드의 가독성에 큰 영향을 미치지 않습니다.물론 필수는 아니고 쉽게 생략할 수 있지만, 단순히 "라벨을 사용하는 것이 나쁘다"는 이유로 사용하지 않는 것은 이 경우 좋은 주장이 아닙니다.결국 다른 사람들이 이미 언급한 것처럼 레이블을 제거한다고 해서 코드를 훨씬 쉽게 읽을 수 있는 것은 아닙니다.

이 질문은 알고리즘 최적화에 관한 것이 아니었지만 어쨌든 감사합니다 ;-)

내가 이 글을 작성할 당시에는 continue라는 라벨이 붙은 것을 읽기 쉬운 솔루션으로 간주했습니다.

나는 그래서 물었다 질문 Java의 레이블에 대한 규칙(레이블이 모두 대문자인지 여부)에 대해 설명합니다.

기본적으로 모든 답변은 "사용하지 마십시오. 항상 더 좋은 방법이 있습니다!"라고 말했습니다.리팩토링!".그래서 저는 더 읽기 쉬운(따라서 더 나은?) 솔루션을 요청하기 위해 이 질문을 게시했습니다.

지금까지 나는 지금까지 제시된 대안에 완전히 확신하지 못했습니다.

오해하지 마세요.라벨은 대부분의 경우 사악합니다.

하지만 내 경우에는 조건부 테스트가 매우 간단하고 알고리즘은 수학 논문에서 가져온 것이므로 가까운 시일 내에 변경되지 않을 가능성이 매우 높습니다.그래서 나는 checkMatrixAtRow(x)와 같은 다른 메소드로 스크롤하는 것보다 모든 관련 부분을 한 번에 표시하는 것을 선호합니다.

특히 더 복잡한 수학적 알고리즘에서는 "좋은" 함수 이름을 찾는 것이 꽤 어렵다는 것을 알았습니다. 하지만 그것은 또 다른 질문인 것 같습니다.

나는 레이블이 붙은 루프가 너무 흔하지 않아서 당신에게 맞는 레이블 지정 방법을 선택할 수 있다고 생각합니다. 거기에 있는 것은 계속해서 당신의 의도를 완벽하게 명확하게 만듭니다.

원래 질문의 루프를 리팩터링하도록 제안하고 이제 문제의 코드를 본 후에는 매우 읽기 쉬운 루프가 있다고 생각합니다.

제가 상상했던 것은 매우 다른 코드 덩어리였습니다. 실제 예제를 올려보면 제가 생각했던 것보다 훨씬 깔끔하다는 것을 알 수 있습니다.

오해를 드려 죄송합니다.

이것이 당신에게 효과가 있습니까?내부 루프를 CheckedEntireMatrix 메소드로 추출했습니다(나보다 이름을 더 잘 지정할 수 있음). 또한 내 Java는 약간 녹슬었습니다.하지만 내 생각엔 그게 메시지를 전달하는 것 같아

for( int idx = 0; idx < vectorLength; idx++) {
    if( conditionAtVectorPosition( v, idx ) 
    || !CheckedEntireMatrix(v)) continue;

    setValueInVector( v, idx );
}

private bool CheckedEntireMatrix(Vector v)
{
    for( rowIdx = 0; rowIdx < n; rowIdx++ ) {
        if( anotherConditionAtVector( v, rowIdx ) ) continue;
        if( conditionAtMatrixRowCol( m, rowIdx, idx ) ) return false;
    }   
    return true;
}

Gishu는 올바른 생각을 가지고 있습니다.

for( int idx = 0; idx < vectorLength; idx++) {
    if (!conditionAtVectorPosition( v, idx ) 
        && checkedRow(v, idx))
         setValueInVector( v, idx );
}

private boolean checkedRow(Vector v, int idx) {
    for( rowIdx = 0; rowIdx < n; rowIdx++ ) {
        if( anotherConditionAtVector( v, rowIdx ) ) continue;
        if( conditionAtMatrixRowCol( m, rowIdx, idx ) ) return false;
    }  
    return true;
}

첫 번째 계속을 이해하는 것이 확실하지 않습니다.나는 Gishu를 복사하여 다음과 같이 작성합니다(실수한 부분이 있으면 죄송합니다).

for( int idx = 0; idx < vectorLength; idx++) {
    if( !conditionAtVectorPosition( v, idx ) && CheckedEntireMatrix(v))
        setValueInVector( v, idx );
}

inline bool CheckedEntireMatrix(Vector v) {
    for(rowIdx = 0; rowIdx < n; rowIdx++)
        if ( !anotherConditionAtVector(v,rowIdx) && conditionAtMatrixRowCol(m,rowIdx,idx) ) 
            return false;
    return true;
}

@새디:

알고리즘 자체보다는 코드 메커니즘에 더 많은 코드를 소비한다는 점에서 모두 원본보다 가독성이 떨어지는 것처럼 보입니다.

두 번째 루프를 알고리즘 외부로 외부화한다고 해서 반드시 가독성이 떨어지는 것은 아닙니다.메소드 이름을 잘 선택하면 가독성을 높일 수 있습니다.

그 중 일부는 깨졌거나 편집되기 전의 내용이었습니다.가장 끔찍한 것은 사람들이 라벨 없이 코드를 작성하고 어떤 것도 깨지지 않는 방법에 대해 매우 열심히 생각해야 한다는 사실입니다.

나는 다른 관점을 가지고 있습니다:그 중 일부는 원래 알고리즘의 동작을 파악하기 어렵기 때문에 깨졌습니다.

일부에서는 동일한 테스트를 두 번 실행하면 성능이 저하되는데, 이는 항상 사소한 것은 아닙니다.이에 대한 대안은 부울 값을 저장하고 전달하는 것인데, 이는 추악합니다.

성능 저하가 미미합니다.그러나 테스트를 두 번 실행하는 것은 좋은 해결책이 아니라는 데 동의합니다.

코드의 관련 부분을 메소드로 리팩토링하는 것은 사실상 아무 작업도 하지 않습니다.코드가 파일에 배치되는 방식을 재정렬하지만 실행 방식에는 영향을 미치지 않습니다.

요점이 보이지 않습니다.응, 행동은 바뀌지 않아...리팩토링?

확실히 레이블이 잘못 사용되어 리팩터링되어야 하는 경우가 있습니다.나는 그것이 깨지지 않는 규칙으로 취급되어야 한다고 생각하지 않습니다.

나는 전적으로 동의합니다.그러나 당신이 지적했듯이 우리 중 일부는 이 예제를 리팩토링하는 동안 어려움을 겪습니다.초기 예제를 읽을 수 있더라도 유지 관리가 어렵습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow