where 조건과 continue 가드 절을 사용하여 foreach 필터링

일부 프로그래머가 이것을 사용하는 것을 보았습니다.

foreach (var item in items)
{
    if (item.Field != null)
        continue;

    if (item.State != ItemStates.Deleted)
        continue;

    // code
}

내가 일반적으로 사용하는 대신

foreach (var item in items.Where(i => i.Field != null && i.State != ItemStates.Deleted))
{
    // code
}

나는 둘 다의 조합을 보았습니다. 나는 특히 더 복잡한 조건에서 '계속'으로 가독성을 좋아합니다. 성능에 차이가 있습니까? 데이터베이스 쿼리를 사용한다고 가정합니다. 일반 목록은 어떻습니까?

나는 이것을 명령 / 쿼리 분리 를 사용하기에 적절한 장소로 간주합니다 . 예를 들면 다음과 같습니다.

// query
var validItems = items.Where(i => i.Field != null && i.State != ItemStates.Deleted);
// command
foreach (var item in validItems) {
    // do stuff
}

또한 쿼리 결과에 자체 문서화 이름을 지정할 수 있습니다. 또한 데이터를 쿼리하거나 수정하는 코드를 리팩토링 할 기회를 찾는 데 도움이됩니다. 두 가지를 모두 시도하는 혼합 코드보다 데이터 만 쿼리하거나 변경하는 코드가 훨씬 쉽습니다.

디버깅 할 때 해결 foreach내용 validItems이 예상 한대로 신속하게 확인 되기 전에 중단 할 수 있습니다 . 필요한 경우가 아니면 람다에 들어 가지 않아도됩니다. 람다로 들어가야하는 경우 별도의 함수로 분해하여 제안하는 것이 좋습니다.

성능에 차이가 있습니까? 쿼리는 데이터베이스에 의해 뒷받침된다면, LINQ 버전은이 잠재적 인 SQL 쿼리가 있기 때문에, 더 빠르게 실행할 수 있습니다 더 효율적입니다. LINQ to Objects 인 경우 실제 성능 차이가 나타나지 않습니다. 항상 그렇듯이 최적화를 미리 예측하지 않고 코드를 프로파일 링하고 실제로보고되는 병목 현상을 해결하십시오.

물론 성능에 차이가 있으므로 .Where()모든 단일 항목에 대해 델리게이트 호출이 발생합니다. 그러나 성능에 대해 전혀 걱정하지 않습니다.

• 델리게이트 호출에 사용 된 클럭 사이클은 컬렉션을 반복하고 조건을 확인하는 나머지 코드에서 사용하는 클럭 사이클과 비교하여 무시할 수 있습니다.

• 델리게이트를 호출 할 때의 성능 저하는 몇 번의 클럭주기 정도이며, 운 좋게도 개별 클럭주기에 대해 걱정해야했던 시절이 지났습니다.

^{어떤 이유로 클럭 사이클 레벨에서 성능이 실제로 중요한 경우 List<Item>대신 대신 을 사용 IList<Item>하여 컴파일러가 가상 호출 대신 직접 (및 inlinable) 호출을 사용할 수 있고 List<T>실제로 반복자 가 a struct, 박스에 넣을 필요는 없습니다. 그러나 그것은 정말 사소한 일입니다.}

데이터베이스 쿼리는 최소한 이론 상으로는 필터를 RDBMS로 보낼 가능성이 있기 때문에 성능이 크게 향상되기 때문에 다른 상황입니다. 일치하는 행만 RDBMS에서 프로그램으로 이동합니다. 그러나 나는 linq를 사용해야한다고 생각하기 때문에이 표현을 그대로 RDBMS에 보낼 수 있다고 생각하지 않습니다.

if(x) continue;이 코드를 디버깅해야하는 순간 의 이점을 실제로 알 수 있습니다. if()s와 continues에 대한 단일 스테핑 은 훌륭하게 작동합니다. 필터링 델리게이트를 한 단계 씩 실행하는 것은 고통스러운 일입니다.