LINQ 및 Lambda Expressions를 사용하면 코드를 덜 읽을 수 있습니까? [닫은]

Linq의 동료와 토론 중입니다. 여기에서 복사하겠습니다.

동료 : 여기에서 솔직 해집니다. Linq 구문이 짜증납니다. 혼란스럽고 직관적이지 않습니다.

나 : 오, T-SQL보다 더 혼란스러워?

동료 : 예.

나 : 그것은 같은 기본 부분을 가지고 있으며, 선택, 어디서, 그리고

동료 : Linq는 나에게 관계형 + OO의 개자식입니다. 공동 작업자 : 잘못 이해하지 마십시오. 엄청나게 강력하지만 SQL을 다시 사용하여 개체 컬렉션을 다시 사용했습니다.

Linq + Lamda를 사용하는 것이 매우 강력하고 (동의 함) 코드를 읽기 쉽게 만듭니다 (그 시점에 동의하지 않음).

pickFiles = from f in pickFolder.GetFiles("*.txt")
where ValidAuditFileName.IsMatch(f.Name)
select f;

또는

var existing = from s in ActiveRecordLinq.AsQueryable<ScannedEntity>()
where s.FileName == f.FullName && s.DocumentType != "Unknown"
select s;

또는 (여기서 VB 코드)

   Dim notVerified = From image In images.AsParallel
     Group Join verifyFile In verifyFolder.GetFiles("*.vfy").AsParallel.Where(
      Function(v) v.Length > 0
      ).AsParallel
   On image.Name.Replace(image.Extension, ".vfy") Equals verifyFile.Name
     Into verifyList = Group
    From verify In verifyList.DefaultIfEmpty
    Where verify Is Nothing
    Select verify

나에게 이것은 깨끗하고 쉽고 (적어도 대안보다 쉽다), 그것에 대한 당신의 의견은 무엇입니까?

더 이상 올바른 게시물을 찾을 수 없지만 Eric Lippert (및 다른 여러 소프트웨어)가 Linq의 선언 방식에 대해 여러 차례 의견을 제시했습니다 . 이는 몇 가지 문제 클래스에서 명령 구문 보다 훨씬 직관적 입니다.

Linq를 사용하면 메커니즘이 아니라 의도 를 표현하는 코드를 작성할 수 있습니다 .

어느 것이 더 읽기 쉬운 지 말해주십시오. 이:

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    List<Customer> results = new List<Customer>();
    foreach (Customer c in source)
    {
        if (c.FirstName == "Aaron")
        {
            results.Add(c);
        }
    }
    results.Sort(new LastNameComparer());
    return results;
}

class LastNameComparer : IComparer<Customer>
{
    public int Compare(Customer a, Customer b)
    {
        return x.LastName.CompareTo(b.LastName);
    }
}

아니면 이거?

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    return from c in source
           where c.FirstName == "Aaron"
           orderby c.LastName
           select c;
}

아니면 이것도?

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    return source.Where(c => c.FirstName == "Aaron").OrderBy(c => c.LastName);
}

첫 번째 예는 가장 간단한 결과를 얻기 위해 무의미한 상용구입니다. Linq 버전보다 더 읽기 쉽다고 생각하는 사람은 머리를 검사해야합니다. 뿐만 아니라 첫 번째 메모리는 메모리를 낭비합니다. yield return정렬 때문에 사용하여 작성할 수도 없습니다 .

동료가 원하는 것을 말할 수 있습니다. 개인적으로, 나는 Linq에 개선 것 같아요 내 무척 코드의 가독성을.

Linq에 대한 "관계"는 없습니다. SQL과 표면적 인 유사성이 있지만 관계형 미적분을 구현하기 위해 어떤 모양이나 형태로도 시도하지는 않습니다. 시퀀스를보다 쉽게 ​​쿼리하고 프로젝트 할 수있게 해주는 확장 기능입니다. "쿼리"는 "관계형"을 의미하지 않으며 실제로 SQL과 같은 구문을 사용하는 비 관계형 데이터베이스가 여러 개 있습니다. Linq는 순전히 객체 지향적이며 C # 팀의 일부 표현 트리 부두 및 영리한 디자인으로 인해 Linq to SQL과 같은 프레임 워크를 통해 관계형 데이터베이스와 함께 작동하여 익명 함수를 암시 적으로 표현 트리로 변환 할 수 있습니다.

동료 : 여기에서 솔직 해집니다. Linq 구문이 짜증납니다. 혼란스럽고 직관적이지 않습니다.

그 비판에 대해서는 논쟁 할 수 없습니다. 동료에게는 짜증나게 합니다. 명확하고 직관적 인 구문을 설계하지 못했습니다. 그것은 우리의 실패이며, 당신은 당신의 동료에게 사과를 전할 수 있습니다. 더 나은 방법을 제안합니다. 동료가 구체적으로 혼란 스럽거나 직관적이지 않은 것은 무엇입니까?

그러나 모든 사람을 기쁘게 할 수는 없습니다. 내 개인적인 의견과 내가 그 주제에 관해 이야기 한 대부분의 사람들의 의견은 쿼리 이해 구문이 동등한 명령 구문보다 훨씬 명확하다는 것입니다. 분명히 모든 사람이 동의하는 것은 아니지만, 운 좋게도 언어 디자인을 할 때 수백만 명의 고객에 대한 합의가 필요하지 않습니다.

"직관적 인"이라는 주제에 대해, 저는 많은 다른 언어를 공부 한 영어 언어학 자의 이야기를 떠올리게되었으며, 영어에서는 단어가 당신과 같은 순서로 오기 때문에 영어 가 모든 언어 중 최고라고 결론을 내 렸습니다 그들을 생각하십시오 . 프랑스 인과 달리 그들은 "개 흰자위가 고기를 붉게 먹는다"와 같은 것을 끊임없이 말합니다. 프랑스 사람들 이 단어를 올바른 순서 로 생각한 다음 프랑스어 순서 로 말해야 하는 것은 얼마나 어려운 일입니까 ! 프랑스어는 너무 직관적이지 않습니다! 프랑스 인이 그것을 말할 수 있다는 것은 놀라운 일입니다. 그리고 독일인? 그들은 "개가 고기를 먹는다"라고 생각하지만 "고기가 먹는 개"라고 말해야한다!?!

종종 "직관적 인"것은 친숙한 문제 일뿐입니다. "select"절로 쿼리 시작을 중지하기 전에 LINQ 작업에 몇 달 이 걸렸습니다 . 이제는 두 번째 특성이며 SQL 순서는 기괴한 것 같습니다.

그렇습니다! 범위 지정 규칙은 모두 SQL에서 엉망입니다. 동료에게 지적하고 싶은 것은 LINQ가 (1) 변수 및 범위의 도입이 왼쪽에서 오른쪽으로 발생하고 (*), (2) 쿼리가 페이지에 나타나는 순서는 실행 순서 즉, 말할 때

from c in customers where c.City == "London" select c.Name

c는 왼쪽에 스코프에 표시되고 오른쪽을 통해 스코프에 유지됩니다. 그리고 발생하는 순서는 다음과 같습니다. 먼저 "고객"이 평가됩니다. 그런 다음 "where"를 평가하여 시퀀스를 필터링합니다. 그런 다음 필터링 된 시퀀스는 "select"에 의해 투영됩니다.

SQL에는이 속성이 없습니다. 당신이 말하는 경우

SELECT Name FROM Customers WHERE City = 'London'

그런 다음 "이름"은 왼쪽이 아닌 오른쪽에 의해 범위에 들어가고 쿼리는 완전히 엉망인 순서로 실행됩니다. 중간 절이 먼저 평가되고 마지막 절이 평가되고 첫 번째 절이 평가됩니다. 지금은 오랫동안 LINQ와 함께 일한 적이있어 미쳤고 직관적이지 않은 것 같습니다.

(*) 범위 지정 규칙은 LINQ에서 join 절을 사용하면 약간 이상합니다. 그러나 그 외에는 범위가 멋지게 중첩됩니다.

프로그래밍 세계의 다른 것들과 마찬가지로 구문에 익숙해지면 (잠재적으로) 읽기가 더 쉽습니다.

프로그래밍 세계의 다른 것들과 마찬가지로 스파게티 코드 또는 기타 남용의 가능성이 있습니다.

프로그래밍 세계의 다른 어떤 것과 마찬가지로, 이런 식으로 또는 다른 방법으로 할 수 있습니다.

프로그래밍 세계의 다른 것과 마찬가지로 마일리지가 다를 수 있습니다.

LINQ / 람다와 관련하여 "컴퓨터에서 읽을 수있는 것이 아니라 사람이 읽을 수있는 코드를 작성하십시오"라는 내용의 주석 / 발언을 보았습니다.

이 문장에는 많은 장점이 있다고 생각하지만, 어셈블리, 절차, OO, 관리, 고 처리량 작업 병렬 솔루션을 통해 개발 언어의 전체 영역을 거친 개발자 (예 : 나 자신)를 고려하십시오. .

나는 코드를 가능한 한 읽기 쉽고 재사용 가능하게 만들고 다양한 GOF 디자인 패턴 원칙을 채택하여 다양한 이기종 사업 부문에 걸쳐 생산 품질 시스템과 서비스를 제공하는 데 자부심을 느꼈습니다.

내가 람다 표현을 처음 만났을 때 나는 생각했다 : "그게 대체 뭐야?!" 그것은 친숙하고 (따라서 편한) 명시 적 선언 구문에 반 직관적이었습니다 . 그러나 구직자에있는 더 젊은 <5yrs는 그러나 그것이 하늘에서 만나였던 것처럼 그것을 때렸다!

컴퓨터처럼 (구문 적 의미에서) 생각하는 것은 언어와 상관없이 직접 코딩 구문으로 매우 쉽게 번역되기 때문입니다. 20 + yr (제 경우 30 +)에 대한 계산적 사고 방식을 가졌을 때 람다 식 의 초기 구문 충격 이 쉽게 두려움과 불신으로 이어질 수 있음을 알아야합니다 .

OP의 동료는 나 자신과 비슷한 배경에서 온 것일 수도 있고 (즉, 몇 번이나 블록 주위에 있었을 수도 있음) 당시에는 반 직관적 이었을까요? 내 질문은 : 당신은 그것에 대해 무엇을 했습니까? 인라인 구문의 이점을 이해하도록 동료를 다시 교육 시키려고 했습니까? 아니면 "프로그램과 함께 있지 않음"으로 인해 필적 / 비방 한 적이 있습니까? 전자는 아마도 당신의 동료가 당신의 생각의 선으로 돌아 오는 것을 보았을 것입니다. 후자는 아마도 LINQ / 람다 구문을 더욱 불신하게 만들 것이고 따라서 부정적인 의견을 악화시킬 것입니다.

나 자신을 위해서 나는 내 자신의 사고 방식을 다시 교육해야했다. (에릭이 암시 한 것처럼, 그것은 의미있는 변화가 아니며, 80 년대 미란다에서 프로그래밍해야했기 때문에 함수형 프로그래밍 경험을 공유했다) 그러나 일단 그 고통을 겪고 나면 그 이점은 명백하지만 더 중요하게는 사용법이 과도하게 사용 된 곳 (즉, 그것을 사용하기 위해 사용 된 곳), 복잡하고 반복적 인 경우 (그러한 경우 DRY 원칙을 고려할 때)입니다.

여전히 많은 코드를 작성하고 기술적으로 많은 코드를 검토해야하는 사람은 항목을 공정하게 검토 할 수 있도록 이러한 원칙을 이해하고 람다 식의 사용이 더 효율적일 수있는 곳을 조언해야합니다. 읽을 수 있고 개발자가 매우 복잡한 인라인 람다 식의 가독성을 고려할 수 있도록합니다 (이 경우 메서드 호출은 코드를보다 읽기 쉽고 유지 보수 가능하며 확장 가능하게 만듭니다).

누군가가 "람다를 얻지 않습니까?" 또는 LINQ 구문을 사용하는 것보다는 루다이 트 가 기본 원리를 이해하도록 돕기 위해 노력합니다. 그들은 결국 나와 같은 "오래된 학교"배경을 가질 수 있습니다.

쿼리가 너무 길면 Lambda Expressions로 인해 코드를 읽을 수 없게됩니다. 그러나 너무 많은 중첩 루프 보다 훨씬 낫습니다 .

두 가지를 혼합 하면 더 좋습니다 .

더 빠르거나 빠르면 읽기 쉬운 Lambda로 작성하십시오.

나는 누군가가 무슨 일이 일어나고 있는지에 대한 아이디어를 얻거나 작은 세부 사항을 쉽게 찾을 수 있는지 여부를 "읽을 수있는"것을 의미하는지에 따라 대부분의 경우 (매우 기괴한 일을 제외하고는) 의존한다고 생각합니다.

링크는 전자에 도움이되지만 종종 (특히 디버깅 할 때) 후자가 아프다고 생각합니다.

코드를 볼 때 IMHO는 전자에 익숙하지 않은 것이 후자보다 훨씬 중요하므로 훨씬 더 읽기 쉽습니다.

LINQ 구문은 직관적이고 읽기 쉽습니다. 특히 SQL과 같은 중간 대신 FROM을 시작 부분에 배치하기 때문에 특히 그렇습니다. 그러나 IMO 람다는 혼란스럽고 코드를 읽기 어렵게 만듭니다.

Linq 구문이 T-SQL과 크게 다르지 않다는 것에 동의합니다. 동료가 실제로 멋지고 반짝이는 OO 코드가 섞여있는 관계형 물건에 반대하고 있다고 생각합니다. 반면에 함수형 프로그래밍에는 약간 익숙해지고 익숙해지기를 원합니다.

따라 다릅니다. 분명히, T-SQL은 일부 DB 관계형 솔루션을 고유하게 제공합니다. 분명히 LINQ는 일부 OO 솔루션을 고유하게 제공합니다.

하나; "T-SQL보다 더 혼란 스러운가?" -초기 질문에서 논의 / 질문됩니다. 이것은 기존의 답변 중 어느 것도 해결하지 못하고 과거에 갇혀 있다고 (명백하게 SQL에 익숙한) 비평가를 비난하는 일부 기능을 분명히 의미합니다.

따라서 특정 품질에 대해 LINQ에 감사하고 기존 답변에 크게 동의하지 않더라도 반대 점은 대표 할 만하다고 생각합니다.

LINQ에 익숙해지면서 몇 년이 지난 후에도 특정 유형의 그룹 작업, 외부 조인 및 비 균등 조인, 복합 키 작업 및 LINQ의 다른 작업을 수행해도 여전히 위험에 빠지게됩니다. (특히 성능에 민감한 질문으로 관계형 백엔드를 대상으로하는 경우)

from c in categories
join p in products on c equals p.Category into ps
from p in ps.DefaultIfEmpty()

그것이 직관적이라고 생각한다면, 당신에게는 더 많은 힘이 있습니다. ;)

Linq가 짜증나는 이유가있을 수 있습니다. 이러한 교과서 예제 대신 실제 사례를 만들어보십시오.

linqlamdathings 에서이 기능을 보여 주려고하면 고전적인 방법으로 읽을 수있는 동안 모든 아름다움이 사라 졌다는 것을 알 수 있습니다. 지연된 실행 문제와 설정 중단 점은 말할 것도 없습니다.

진실은 LinqLambda입니다. 몇 가지 경우에 매우 유용하며 여러분이 결코 이해하지 못하는 모든 멋진 객체 방향을 대체하지는 않습니다.

    public IList<Customer> GetVipCustomers(IList<Customer> source, int maxCount)
    {
        var results = new SortedList<string,Customer>();

        foreach (Customer c in source)
        {
            if (maxCount == results.Count)
                break;

            if (c.IsVip && c.FirstName== "Aaron" || c.SecondName== "Aaron")
                results.Add(c.LastName, c);
        }

        return results.Values;
    }