Czy użycie wyrażeń LINQ i Lambda prowadzi do mniej czytelnego kodu? [Zamknięte]

43

Rozmawiam ze współpracownikiem na temat Linq, skopiuję tutaj:

Współpracownik: Bądźmy szczerzy tutaj. Składnia Linq jest do bani. Jest to mylące i nieintuicyjne.

Ja: och, daj spokój, bardziej zagmatwany niż T-SQL?

Współpracownik: tak.

Ja: ma te same podstawowe części, wybierz, gdzie i skąd

Współpracownik: Linq jest dla mnie draństwem relacji + OO. Współpracownik: Nie zrozum mnie źle - jest niewiarygodnie potężny, ale zmienili przeznaczenie SQL na wykorzystanie kolekcji obiektów.

Uważam, że używanie Linq + Lamdy jest bardzo wydajne (zgadza się), a także ułatwia czytanie kodu (nie zgadza się w tej kwestii):

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

lub

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

lub (tutaj kod 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

Dla mnie jest to czyste i łatwe (przynajmniej łatwiejsze niż alternatywy) do przeczytania, jakie są twoje opinie na ten temat?

Czarny lód
źródło
11
Ogólnie rzecz biorąc, ludzie nienawidzą zmiany. Duży procent nienawidzi go tak bardzo, że się go boi.
Tony
9
Spójrzmy prawdzie w oczy ... linq to po prostu głupia funkcjonalna składnia programowania dodana do C # i VB.Net. Walenie z wyrażeniami linq i lambda to po prostu powiedzenie „FP jest do bani”. Tak mówi twój współpracownik. Myślę, że ta debata została przeprowadzona gdzie indziej.
Scott Whitlock,
48
Czy innym przeszkadza to, że ludzie używają słowa „intuicyjny”, kiedy naprawdę mają na myśli „znajomy”?
Larry Coleman,
7
W każdym razie zespół C # (w tym Eric Lippert) starał się wyjaśnić, że Linq nie był portingiem SQL, został zaprojektowany od podstaw, jak większość innych funkcji. Chciałbym powiedzieć, że twoim współpracownikiem jest luddyta.
Aaronaught,
16
Za to, co jest warte: po prostu kazałem mojej żonie (administratorowi biura - przy zerowym praktycznym doświadczeniu w programowaniu) spojrzeć na 3 przykłady aaronaught i byłem w stanie znacznie łatwiej rozszyfrować intencje przykładów linq i lambda niż tradycyjny przykład imperatywny.
Steven Evers,

Odpowiedzi:

73

Nie mogę już znaleźć właściwego postu, ale Eric Lippert (i być może kilka innych dodatków) kilkakrotnie wypowiadał się na temat deklaratywności Linq , co w przypadku kilku klas problemów jest znacznie bardziej intuicyjne niż składnia imperatywna .

Linq umożliwia pisanie kodu, który wyraża zamiar , a nie mechanizm .

Powiedz mi, co jest łatwiejsze do odczytania. To:

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);
    }
}

Albo to?

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

A może nawet to?

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

Pierwszy przykład to po prostu garść bezsensownych bojlerów, aby uzyskać najprostsze wyniki. Każdy, kto uważa, że ​​jest bardziej czytelny niż wersje Linq, musi zbadać jego głowę. Nie tylko to, ale pierwsze marnuje pamięć. Nie możesz nawet napisać tego używając yield returnsortowania.

Twój współpracownik może powiedzieć, co chce; osobiście uważam, że Linq niezmiernie poprawił moją czytelność kodu.

W Linq też nie ma nic „relacyjnego”. Może mieć pewne powierzchowne podobieństwa do SQL, ale nie próbuje w żadnym kształcie ani formie zaimplementować rachunku relacyjnego. To tylko kilka rozszerzeń, które ułatwiają wyszukiwanie i wyświetlanie sekwencji. „Zapytanie” nie oznacza „relacyjnego”, a w rzeczywistości istnieje kilka nierelacyjnych baz danych, które wykorzystują składnię podobną do SQL. Linq jest zorientowany czysto obiektowo, po prostu zdarza się, że współpracuje z relacyjnymi bazami danych poprzez frameworki, takie jak Linq do SQL, z powodu niektórych drzewek wyrażeń voodoo i sprytnego projektu zespołu C #, dzięki czemu anonimowe funkcje można w sposób niejawny przekształcać w drzewa wyrażeń.

Aaronaught
źródło
6
+1 Jeśli nie podoba ci się LINQ, to prawdopodobnie dlatego, że „nie robisz tego dobrze” :)
Darknight
1
Linq is purely object-oriented+1 za to. Z tego powodu nasz przewodnik po stylu zespołu wymusza stosowanie płynnej składni zamiast składni zapytania. Uważam, że sprawia to, że charakter linku OO jest bardziej oczywisty dla kogoś, kto sprzeciwia się notacji w językach podobnych do C.
SBI,
1
Wiem, że post ma 7 lat. Ale oto pytanie: czy używałeś języków funkcjonalnych jako głównych narzędzi przed spotkaniem z Linq?
Sergey.quixoticaxis.Ivanov,
4
Szczerze mówiąc, wolę pętlę Foor, ponieważ wtedy od razu widzę, gdzie możemy i będziemy mieć wyjątki NULL-referencyjne, jak jest traktowane null i nie jest to odroczone wykonanie, które utrudnia debugowanie, i nie tworzy n list również, więc pętla for jest również bardziej wydajna.
Quandary
1
@Aaronaught, jeśli usuniesz sortowanie i sformatujesz kod proceduralny w stylu Horstmanna , powiem, że jest on bardziej czytelny niż wersja LINQ . I zgodnie z zasadą pojedynczej odpowiedzialności, sortowanie w rzeczywistości nie należy do tego GetVipCustomers(), co, jak sama nazwa wskazuje, zwraca kolekcję klientów VIP, w dowolnej kolejności. W rzadkich przypadkach, w których ważna jest kolejność, takich jak wyświetlanie na ekranie, niech dzwoniący posortuje kolekcję.
Ant_222,
69

Współpracownik: Bądźmy szczerzy tutaj. Składnia Linq jest do bani. Jest to mylące i nieintuicyjne.

Z tą krytyką nie można się kłócić. Dla twojego współpracownika jest do bani . Nie udało się zaprojektować składni, która byłaby dla nich jasna i intuicyjna. To nasza wina i możesz przekazać moje przeprosiny swojemu współpracownikowi. Cieszę się, że mogę zasugerować, jak to zrobić lepiej; co konkretnie twój współpracownik uważa za mylące lub nieintuicyjne?

Jednak nie możesz zadowolić wszystkich. Moja osobista opinia oraz opinia większości osób, z którymi rozmawiałem na ten temat, jest taka, że ​​składnia rozumienia zapytania jest znacznie bardziej przejrzysta niż równoważna składnia imperatywna. Oczywiście nie wszyscy się z tym zgadzają, ale na szczęście nie wymagamy konsensusu od wszystkich milionów naszych klientów, gdy projektujemy język.

Na temat tego, co jest „intuicyjne”, przypomina mi się historia angielskiego lingwisty, który studiował wiele różnych języków i ostatecznie stwierdził, że angielski jest najlepszy ze wszystkich języków, ponieważ w języku angielskim słowa są w tej samej kolejności, w jakiej pomyśl im . W przeciwieństwie do francuskiego, gdzie ciągle mówią takie rzeczy, jak: „biały pies zjada mięso czerwone”. Jak trudno musi Francuzom myśleć słowa we właściwej kolejności, a następnie wymawiać je w kolejności francuskiej ! Francuski jest taki nieintuicyjny! To niesamowite, że Francuzom się to mówi. A niemiecki? gdzie myślą, że „pies je mięso”, a potem muszą powiedzieć „pies je mięso”!?!

Często to, co jest „intuicyjne”, jest jedynie kwestią znajomości. Zajęło mi miesiące pracy z LINQ, zanim przestałem zaczynać zapytania z klauzulą ​​„select”. Teraz jest to druga natura, a kolejność SQL wydaje się dziwna.

Który to jest! Reguły określania zakresu są pomieszane w SQL. Warto zwrócić uwagę współpracownikowi na to, że LINQ został starannie zaprojektowany, aby (1) wprowadzenie zmiennych i zakresów odbywało się od lewej do prawej (*), oraz (2) kolejność, w jakiej zapytanie pojawia się na stronie: kolejność, w jakiej jest wykonywana. To znaczy, kiedy mówisz

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

c pojawia się w zakresie po lewej stronie i pozostaje w zakresie przez prawo. Kolejność, w jakiej się to dzieje, jest następująca: najpierw oceniani są „klienci”. Następnie oceniane jest „gdzie” w celu przefiltrowania sekwencji. Następnie filtrowana sekwencja jest rzutowana przez „select”.

SQL nie ma tej właściwości. Jeśli powiesz

SELECT Name FROM Customers WHERE City = 'London'

następnie „Nazwa” jest wprowadzana w zakres przez coś po prawej, a nie po lewej, a zapytanie jest wykonywane w całkowicie pomieszanej kolejności; środkowa klauzula jest oceniana jako pierwsza, potem ostatnia, a następnie pierwsza. To wydaje mi się teraz szalone i nieintuicyjne, ponieważ tak długo pracowałem wyłącznie z LINQ.


(*) Reguły określania zakresu są trochę dziwne w LINQ z klauzulami łączenia. Ale poza tym lunety ładnie się zagnieżdżają.

Eric Lippert
źródło
5
Nitpick: W języku niemieckim „Der Hund frisst das Fleisch” jest w rzeczywistości tą samą kolejnością, co w języku angielskim, „Pies je mięso” :) Poza tym zauważyłem, że składnia zapytania LINQ jest bardzo czytelna, kiedy zdałem sobie sprawę, że nie jest to SQL .
Michael Stum
18
@gbjbaanb: Nie uzasadniam składni LINQ na całkowicie subiektywnej podstawie, ponieważ jest ona bardziej zrozumiała . Uzasadniam raczej całkowicie obiektywnie, że o wiele łatwiej jest zaprojektować narzędzia, które pomagają użytkownikowi w tworzeniu zapytań LINQ, ponieważ składnia LINQ została zaprojektowana z myślą o narzędziach i że łatwiej jest mentalnie zrozumieć kolejność, w której zdarzenia występują w zapytaniu, ponieważ są uporządkowane leksykalnie.
Eric Lippert,
2
Eric, Z perspektywy programistycznej stylu deklaratywnego rozumiem, że Linq jest odpowiedni (mówię, że jest czytelny) niż SQL. Ale czy jest bardziej czytelny dla ludzi niż SQL? Nie ma mowy. Jeśli „pies zjada mięso czerwone” jest trudny, o ile łatwiej jest „z kuchni, w której kolor jest czerwony, dostać nóż”? W rzeczywistości wszyscy rozmawiamy i myślimy: „weź ten nóż, który jest na stole z kuchni”. I właśnie tam SQL jest bliższy prawdziwemu życiu niż LINQ.
nawfal
6
Chcę filiżankę kawy od Starbucks, gdzie sklep jest otwarty do północy. Czy to brzmi znajomo? Jest w dokładnie takiej samej kolejności jak zapytanie SQL. Tak, LINQ może być bardziej czytelny niż niepotrzebny kod, który trzeba wygenerować, aby wykonać standardowe zapytanie SQL, ale LINQ nie jest bardziej czytelny niż samo zapytanie SQL. Więc tak; może być korzystne dla programistów LINQ zakres od lewej do prawej, ale jako użytkownik, dlaczego mnie to obchodzi? Dbam tylko o użyteczność.
KyleM
8
@KyleM: Oczywiście; użyteczność była bardzo ważnym aspektem projektu LINQ. W szczególności kluczowa była podatność na narzędzia zwiększające wydajność . Ponieważ zakresy przepływają od lewej do zapisu w zapytaniu LINQ, do momentu c.wpisania IDE zna już typ ci może dać ci IntelliSense. W LINQ mówisz „od c u klientów, gdzie c.” i bum, IntelliSense pomaga ci, wymieniając członków Customer. W SQL, gdy wpiszesz „WYBIERZ nazwę od klientów”, nie możesz uzyskać żadnej pomocy IDE, aby powiedzieć, że „nazwa” jest dobrym wyborem, ponieważ pisałeś name wcześniej customers .
Eric Lippert,
22

Jak wszystko inne w świecie programowania, musisz przyzwyczaić się do składni, a wtedy jest (potencjalnie) łatwiejszy do odczytania.

Jak wszystko inne w świecie programowania, istnieje możliwość wystąpienia kodu spaghetti lub innych nadużyć.

Jak wszystko inne w świecie programowania, możesz to zrobić w ten lub inny sposób.

Jak wszystko inne w świecie programowania, przebieg może się różnić.

Wonko przy zdrowych zmysłach
źródło
6

Widziałem komentarz / uwagę, w której coś mówiło - w odniesieniu do LINQ / lambda - w następujący sposób: „Napisz kod czytelny dla ludzi, a nie dla twojego komputera”.

Myślę, że to stwierdzenie ma wiele zalet, jednak weź pod uwagę programistę (takiego jak ja), który przeszedł całą gamę języków programowania od montażu, poprzez procedury, przez OO, poprzez zarządzanie, poprzez wykorzystanie rozwiązań o wysokiej przepustowości równoległych zadań .

Szczyciłem się tym, że mój kod jest tak czytelny i jak to możliwe, że można go ponownie wykorzystać, i że zastosowałem wiele zasad wzornictwa projektowego GOF w celu dostarczenia systemów i usług jakości produkcji w wielu różnych sektorach biznesowych.

Gdy pierwszy raz spotkałem wyrażenie lambda, pomyślałem: „Co to do diabła jest!?!” Było to natychmiast sprzeczne z intuicją w stosunku do mojej znanej (i dlatego wygodnej) wyraźnej składni deklaratywnej. Młodsi w wieku <5 lat w pracy chłopaki jednak to zrobili, jakby to była manna z nieba!

Dzieje się tak dlatego, że przez lata myślenie jak komputer (w sensie syntaktycznym) bardzo łatwo przekładało się na składnię kodowania bezpośredniego (niezależnie od języka). Kiedy masz już obliczeniowy sposób myślenia przez około 20 lat (w moim przypadku 30+), musisz docenić, że początkowy szok syntaktyczny wyrażenia lambda może łatwo przełożyć się na strach i nieufność.

Może współpracownik w PO pochodził z podobnego środowiska jak ja (tj. Był kilka razy w okolicy) i było to dla nich sprzeczne z intuicją? Moje pytanie brzmi: co zrobiłeś z tym? Czy próbowałeś ponownie wyedukować rówieśnika, aby rozumiał korzyści płynące ze składni wbudowanej, czy też pręgowałeś go / krytykowaliście za to, że „nie byli w programie”? Ten pierwszy prawdopodobnie widziałby, jak twój współpracownik podszedł do twojego sposobu myślenia, ten drugi prawdopodobnie spowodowałby, że jeszcze bardziej nie ufają składni LINQ / lambda, a tym samym pogarszają negatywną opinię.

Dla siebie musiałem ponownie wyedukować swój sposób myślenia (jak mówi Eric powyżej, nie jest to nieznaczna zmiana umysłu i musiałem programować w Mirandzie w latach 80., więc miałem swój udział w funkcjonalnym programowaniu) ale kiedy już przeszedłem przez ten ból, korzyści były oczywiste, ale - co ważniejsze - tam, gdzie jego użycie zostało nadmiernie wykorzystane (tj. użyte w celu użycia go), ponad złożone i powtarzalne (biorąc pod uwagę zasadę DRY w tym przypadku).

Ponieważ ktoś, kto nie tylko nadal pisze dużo kodu, ale również musi dokonać przeglądu technicznego dużo kodu, konieczne było zrozumienie tych zasad, aby móc bezstronnie przeglądać elementy, doradzając, gdzie użycie wyrażenia lambda może być bardziej wydajne / czytelny, a także zachęcić programistów do rozważenia czytelności bardzo złożonych wbudowanych wyrażeń lambda (w których wywołanie metody - w takich przypadkach - uczyniłoby kod bardziej czytelnym, łatwym do utrzymania i rozszerzalnym).

Więc kiedy ktoś mówi, że „nie dostaje lambda?” lub składnia LINQ, zamiast nazywać je luddysem, próbując pomóc im zrozumieć podstawowe zasady. Mogą przecież mieć „oldskulowe” pochodzenie, takie jak ja.

CWC
źródło
Ciekawy komentarz - miałem to po przejściu z silnie typowanych języków statycznych na języki dynamiczne. Trochę czasu zajęło mi przystosowanie się (strach i nieufność), a teraz trudno mi wrócić, szczerze mówiąc.
lunchmeat317
4

Wyrażenia lambda prowadzą do mniej czytelnego kodu, jeśli zapytania są zbyt długie. Jest to jednak znacznie lepsze niż zbyt wiele zagnieżdżonych pętli .

Lepiej jest z mieszanką tych dwóch .

Napisz w Lambda, jeśli jest szybszy (potrzebujesz, żeby był szybki) lub łatwiejszy do odczytania.

Amir Rezaei
źródło
Tak, ale co sprawiłoby, że linq / lamda nie byłby łatwiejszy do odczytania?
BlackICE,
przepraszam, oznaczało, że nie jest łatwiejsze do odczytania niż alternatywa.
BlackICE,
1

Myślę, że w większości przypadków (z wyjątkiem robienia czegoś bardzo dziwnego) zależy od tego, czy masz na myśli „czytelny” jako ktoś, kto ma pojęcie o tym, co się dzieje, czy też może z łatwością znaleźć wszystkie małe drobne szczegóły.

Myślę, że link pomaga w tym pierwszym, ale często (szczególnie podczas debugowania) boli ten drugi.

IMHO, kiedy patrzę na kod, nie jestem zaznajomiony z tym pierwszym, jest znacznie ważniejszy niż drugi, więc uważam, że jest on znacznie bardziej czytelny.

Rachunek
źródło
Słuszna uwaga. Ten ostatni jest zwykle objęty dobrym testem jednostkowym.
Scott Whitlock,
Więc uważasz, że wewnętrzne elementy oceny linq utrudniają znalezienie wszystkich szczegółów? Czy możesz podać przykład, kiedy to może być?
BlackICE,
3
@David: Wyrażenia Linq są nie tylko leniwe, ale są wyrażeniami . Kod odbierający wyrażenie linq może faktycznie zmodyfikować to wyrażenie, więc robi coś zupełnie innego, na przykład makro lisp działające na wyrażeniach s. Na przykład, podczas pracy z linq na SQL, faktycznie bierze to wyrażenie where e.FirstName == "John"i tłumaczy je na zapytanie SQL! Robi to, patrząc na nieskompilowane (ale parsowane) wyrażenie, widząc, że jest to porównanie właściwości wywoływanej FirstNameprzez utrwalony byt, i to w porównaniu do łańcucha itp. Wiele się dzieje.
Scott Whitlock,
@ David ogólnie nie uważam szczegółów za trudne do znalezienia, dopóki nie zaczniesz używać linq przeciwko sobie. „Prosty” przykład tego, który pochłonął mnie długo, to: bugsquash.blogspot.com/2008/07/y-combinator-and-linq.html, ale w niektórych przypadkach jest o wiele więcej przykładów rzeczy, które ludzie robią z wyrażeniami w obszarach dynamicznych, DynamicObject i IDynamicMetaObjectProvider. To, gdzie rysujesz linię tego, co jest linq, jest dyskusyjne, ale jak zauważa Scott, wszystkie te rzeczy są dostępne dla / w linq, ponieważ linq używa tych samych drzew wyrażeń.
Bill
@Bill w porządku, dam ci to trudne, ale funkcje kombinatora y i wyższego rzędu zranią większość naszych głów, to jest jak rekurencja, masz ją lub nie. Czy rekurencyjna implementacja tego jest łatwiejsza do odczytania (jeśli nie znasz żadnego z nich)?
BlackICE,
1

Uważam, że składnia LINQ jest intuicyjna i łatwa do odczytania, zwłaszcza, że ​​umieszczają FROM na początku tam, gdzie należy zamiast na środku, jak w SQL. Ale lambda IMO są mylące i utrudniają odczytanie kodu.

Mason Wheeler
źródło
Jak myślisz, dlaczego lambdas są mylące? Czy to wnioskowanie typu?
ChaosPandion,
1
@ChaosPandion: Najpierw wnioskowanie typu, a po drugie symbol. Złożenie an = i a razem wygląda jak> = to, że ktoś spieprzył i napisał do tyłu, i to zwykle rzuca mój mózg na pętlę.
Mason Wheeler,
@Mason - Czy podoba Ci się składnia Haskell ( \x -> x * x) czy F # ( fun x -> x * x)?
ChaosPandion,
@ChaosPandion: Nie, nie szczególnie. Lambdas mogą być szybkie w pisaniu, ale trudno mi je przeanalizować, szczególnie gdy stają się niełatwe w złożoności. Twoje przykłady nie są takie złe, ale zwykle stają się znacznie gorsze.
Mason Wheeler,
6
@Mason: Wygląda na to, że sprzeciwiacie się wykorzystywaniu lamdas, a nie w pierwszej kolejności.
Anon.
1

Zgadzam się z Tobą, że składnia Linq nie różni się znacząco od T-SQL. Myślę, że twój współpracownik może naprawdę sprzeciwić się mieszaniu relacji, w których jego ładny i błyszczący kod OO. Z drugiej strony programowanie funkcjonalne wymaga trochę przyzwyczajenia się i chęci przyzwyczajenia się do niego.

Larry Coleman
źródło
0

To zależy. Oczywiście T-SQL w unikalny sposób zapewnia rozwiązania oparte na DB. Oczywiście LINQ wyjątkowo oferuje niektóre rozwiązania OO.

Jednak; „bardziej mylące niż T-SQL?” - jest omawiany / zadawany w pytaniu wstępnym. Wyraźnie implikuje to pewne funkcje, których żadna z istniejących odpowiedzi nie rozwiązuje, zamiast tego oskarża (oczywiście znającego SQL) krytyka, że ​​utknął w przeszłości.

Chociaż doceniam LINQ za pewne cechy i nie bardzo nie zgadzam się z istniejącymi tutaj odpowiedziami, czuję, że kontrapunkt zasługuje na reprezentację:

Wiele lat po zapoznaniu się z LINQ, wykonywanie pewnych rodzajów operacji grupowych, sprzężeń zewnętrznych i innych niż equijoins, praca z kluczami kompozytowymi i inne operacje w LINQ wciąż powodują, że mam zawroty głowy. (Zwłaszcza, gdy celem jest relacyjny back-end z pytaniami wrażliwymi na wydajność).

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

Jeśli uważasz, że to intuicyjne, masz więcej mocy. ;)

Shannon
źródło
-4

Prawdopodobnie jest powód, dla którego Linq jest do bani, po prostu spróbuj tworzyć przykłady z prawdziwego świata, zamiast tych przykładów z podręcznika.

spróbuj pokazać tę funkcję w linqlamdathings, a zobaczysz, że całe piękno zniknęło, a klasyczny sposób pozostaje czytelny. Nie wspominając o odroczonych problemach z wykonaniem i ustawianiu punktów przerwania.

Prawda jest taka, że ​​LinqLambdaThings są bardzo przydatne w kilku przypadkach i nie uważa się, że zastępują one wszystkie zręczne obiekty, których nigdy nie rozumieliście

    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;
    }
Marc
źródło
6
Myślę, że source.Where(c => c.IsVip && c.FirstName == "Aaron" || c.SecondName == "Aaron").Take(maxCount).OrderBy(d => d.LastName);trudno jest je odczytać, więc mogłem się pomylić;)
jk.
1
W jaki sposób uważałeś je za przykłady z podręczników? To jest właściwie kod użycia produkcyjnego. Byłoby to pomocne, gdybyś podał do porównania zarówno swój klasyczny „czytelny” kod, jak i wersję linq / lamda, zamiast oczekiwać od wszystkich konwersji.
BlackICE
3
Czy zarejestrowałeś się specjalnie, aby złożyć skargę na LINQ?
KChaloux
1
@KChalhal Myślę, że po prostu trollowali szczerze mówiąc
jk.