조건을 중복 확인하는 것이 나쁜 스타일입니까?

종종 내 코드에서 특정 조건을 반복해서 확인하는 위치에 도달합니다.

"a"로 시작하는 줄, "b"로 시작하는 줄 및 다른 줄을 포함하는 텍스트 파일이 있고 실제로 처음 두 종류의 줄만 사용하고 싶다고 가정합니다. 내 코드는 다음과 같습니다 (파이썬을 사용하지만 의사 코드로 읽음).

# ...
clear_lines() # removes every other line than those starting with "a" or "b"
for line in lines:
    if (line.startsWith("a")):
        # do stuff
    elif (line.startsWith("b")):
        # magic
    else:
        # this else is redundant, I already made sure there is no else-case
        # by using clear_lines()
# ...

여기 에서이 조건을 확인하지 않을뿐만 아니라 다른 기능에서도 확인할 수 있습니다.

소음으로 생각합니까 아니면 내 코드에 가치를 더합니까?

이는 매우 일반적인 관행이며이를 처리하는 방법은 고차 필터를 사용하는 것 입니다.

기본적으로 필터링하려는 목록 / 시퀀스와 함께 함수를 필터 메서드에 전달하면 결과 목록 / 시퀀스에는 원하는 요소 만 포함됩니다.

나는 파이썬 구문에 익숙하지 않지만 (위 링크에 표시된 것과 같은 기능을 포함하고 있지만) c # / f #에서는 다음과 같습니다.

씨#:

var linesWithAB = lines.Where(l => l.StartsWith("a") || l.StartsWith("b"));
foreach (var line in linesWithAB)
{
    /* line is guaranteed to ONLY start with a or b */
}

f # (이너 머블이라고 가정하고 그렇지 않으면 List.filter가 사용됨) :

let linesWithAB = lines
    |> Seq.filter (fun l -> l.StartsWith("a") || l.StartsWith("b"))

for line in linesWithAB do
    /* line is guaranteed to ONLY start with a or b */

따라서 명확하고 : 검증되고 테스트 된 코드 / 패턴을 사용하면 나쁜 스타일입니다. 즉, clear_lines ()를 통해 나타나는 방식으로 메모리의 목록을 변경하면 스레드 안전성과 병렬 처리에 대한 희망이 사라집니다.

최근에 Motorola S 레코드 형식을 사용하여 펌웨어 프로그래머를 구현해야했습니다 . 시간이 오래 걸리기 때문에 첫 번째 초안은 중복을 무시하고 실제로 응용 프로그램에서 사용해야하는 하위 집합을 기반으로 단순화했습니다. 내 테스트를 쉽게 통과했지만 다른 사람이 시도하자마자 열심히 실패했습니다. 문제가 무엇인지 전혀 알지 못했습니다. 완전히 끝났지 만 결국 실패했습니다.

따라서 문제의 범위를 좁히기 위해 모든 중복 검사를 구현할 수밖에 없었습니다. 그 후 문제를 발견하는 데 약 2 초가 걸렸습니다.

올바른 방법으로 처리하는 데 2 ​​시간이 더 걸렸지 만 문제 해결에 다른 사람들의 시간을 낭비했습니다. 몇 번의 프로세서주기가 문제 해결에 낭비되는 경우는 매우 드 rare니다.

즉, 파일 읽기와 관련하여 전체 파일을 메모리로 읽고 메모리에서 처리하는 대신 파일을 읽고 한 번에 한 줄씩 처리하도록 소프트웨어를 설계하는 것이 유리합니다. 그렇게하면 여전히 매우 큰 파일에서 작동합니다.

else경우에 따라 예외를 제기 할 수 있습니다 . 이 방법은 중복되지 않습니다. 예외는 발생하지 않지만 어쨌든 확인되는 것입니다.

clear_lines() # removes every other line than those starting with "a" or "b"
for line in lines:
    if (line.startsWith("a)):
        # do stuff
    if (line.startsWith("b")):
        # magic
    else:
        throw BadLineException
# ...

에서 계약에 의해 설계 , 하나의 문서에 설명 된대로 각 함수가 작업을 수행해야합니다 추측. 따라서 각 기능에는 사전 조건 목록, 즉 기능 입력 조건, 사후 조건, 즉 기능 출력 조건이 있습니다.

이 기능은 입력이 사전 조건을 준수하는 경우 출력이 사후 조건에 설명 된대로 클라이언트에 보장해야합니다. 사전 조건 중 하나 이상을 준수하지 않으면 함수가 원하는 것을 수행 할 수 있습니다 (충돌, 결과 반환 등). 따라서 사전 및 사후 조건은 기능의 의미 론적 설명입니다.

계약 덕분에 함수는 클라이언트가 올바르게 사용하는지 확인하고 클라이언트는 함수가 올바르게 작동하는지 확인합니다.

일부 언어는 기본적으로 또는 전용 프레임 워크를 통해 계약을 처리합니다. 다른 사람들에게는 @Lattyware가 말한 것처럼 어설 션 덕분에 사전 및 사후 조건을 확인하는 것이 가장 좋습니다. 그러나 나는이 개념이 (사람의) 사용자 입력에 대한 보호에 더 집중되어 있기 때문에 방어 적 프로그래밍이라고 부르지 않을 것입니다.

계약을 악용하는 경우 호출 된 함수가 완벽하게 작동하고 이중 검사가 필요하지 않거나 호출 된 함수가 작동하지 않고 호출 기능이 원하는대로 작동 할 수 있으므로 중복 검사 조건을 피할 수 있습니다.

더 어려운 부분은 어떤 기능이 무엇을 담당하는지 정의하고 이러한 역할을 엄격하게 문서화하는 것입니다.

실제로 시작시 clear_lines ()가 필요하지 않습니다. 라인이 "a"또는 "b"가 아닌 경우 조건부 만 트리거되지 않습니다. 해당 줄을 제거하려면 else를 clear_line ()으로 만드십시오. 서있는 것처럼 문서를 두 번 통과하고 있습니다. 처음에 clear_lines ()를 건너 뛰고 foreach 루프의 일부로 처리하면 처리 시간을 반으로 줄입니다.

그것은 나쁜 스타일 일뿐 만 아니라 계산적으로 나쁩니다.

유효하지 않은 문자열 (예 : 출력 디버그 텍스트)을 찾으면 실제로 무언가를하고 싶다면 절대 괜찮습니다. 알 수없는 이유로 작동이 중지 될 때 몇 줄이 추가되고 몇 개월이 지나면 출력을보고 이유를 찾을 수 있습니다.

그러나 그것을 무시하는 것이 안전하거나 확실하지 않은 문자열을 얻지 못할 경우 여분의 분기가 필요하지 않습니다.

개인적으로 나는 예상치 못한 조건에 대해 최소한 추적 출력을 넣는 데 항상 노력하고 있습니다.

... "a"로 시작하는 줄, "b"로 시작하는 줄 및 기타 줄이 포함 된 텍스트 파일이 있고 실제로 처음 두 종류의 줄만 사용하고 싶습니다. 내 코드는 다음과 같습니다 (파이썬을 사용하지만 의사 코드로 읽음).

# ...
clear_lines() # removes every other line than those starting with "a" or "b"
for line in lines:
    if ...

나는 if...then...else건축을 싫어한다 . 나는 전체 문제를 피할 것이다.

process_lines_by_first_character (lines,  
                                  'a' => { |line| ... a code ... },
                                  'b' => { |line| ... b code ... } )