LINQ ve Lambda Expressions kullanımı daha az okunabilir koda neden olur mu? [kapalı]

Linq'te bir meslektaşım ile bir tartışma yapıyorum, buraya kopyalayacağım:

İş arkadaşı: Burada dürüst olalım. Linq sözdizimi berbat. Kafa karıştırıcı ve sezgisel değil.

Ben: oh hadi, T-SQL'den daha kafa karıştırıcı mı?

İş arkadaşı: evet.

Ben: aynı temel bölümleri var, seçin, nerede ve

İş arkadaşı: Linq, bana göre ilişkisel + OO'nun bir bastardizasyonu. İş arkadaşı: Beni yanlış anlamayın - inanılmaz güçlüdür, ancak nesne koleksiyonlarını tekrar kullanmak için SQL'i yeniden kullandılar.

Linq + Lamda'yı kullanmanın çok güçlü olduğu (kabul eder) ve ayrıca kodu okumayı kolaylaştırdığı kanısındayım (o noktada aynı fikirde değil):

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

veya

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

veya (burada VB kodu)

   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

Bana göre bu temiz ve kolay (en azından alternatiflerden daha kolay) okumak kolay, bu konudaki görüşleriniz neler?

Artık doğru yazıyı bulamıyorum, ancak Eric Lippert (ve muhtemelen birkaç başka softies), Linq’in nasıl açıklayıcı olduğu konusunda, birkaç sorun sınıfı için, zorunlu sözdiziminden çok daha sezgisel olduğu konusunda birkaç kez karar verdim .

Linq , mekanizmayı değil, amacını ifade eden kod yazmanızı sağlar .

Hangisinin daha kolay okunabileceğini söyle. Bu:

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

Veya bu?

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

Veya bu bile?

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

İlk örnek, en basit sonuçları elde etmek için bir sürü anlamsız kazandır. Linq versiyonlarından daha okunaklı olduğunu düşünen birinin kafasını incelemesi gerekir. Sadece bu değil, ilki hafızayı boşa harcıyor. yield returnSıralama nedeniyle kullanarak bile yazamazsınız .

İş arkadaşınız ne istediğini söyleyebilir; şahsen, Linq iyileşmiştir düşünüyorum benim ölçülemeyecek kod okunabilirliği.

Linq hakkında da "ilişkisel" bir şey yok. SQL ile bazı yüzeysel benzerlikleri olabilir, ancak ilişkisel hesabı uygulamak için hiçbir şekilde veya biçimde çalışmaz. Dizileri sorgulamayı ve yansıtmayı kolaylaştıran bir dizi uzantıdır. "Sorgu", "ilişkisel" anlamına gelmez ve aslında SQL benzeri sözdizimini kullanan birkaç ilişkisel olmayan veritabanı vardır. Linq tamamen nesne yönelimlidir, sadece bazı ifade ağacı vudu ve C # ekibinden akıllı tasarım sayesinde anonim işlevleri ifade ağaçlarına dönüştürülebilir hale getirme nedeniyle, Linq to SQL gibi çerçeveler aracılığıyla ilişkisel veritabanlarıyla çalışır.

İş arkadaşı: Burada dürüst olalım. Linq sözdizimi berbat. Kafa karıştırıcı ve sezgisel değil.

Bu eleştiriyle tartışamazsınız. İş arkadaşınız için berbat . Onlar için açık ve sezgisel olan bir sözdizimi tasarlamadık. Bu bizim başarısızlığımızdır ve özürlerimi iş arkadaşınıza iletebilirsiniz. Bunu nasıl daha iyi hale getirebileceğimize dair önerilerde bulunmaktan mutluluk duyuyorum; İş arkadaşınız özellikle ne kafa karıştırıcı veya sezgisel bulmuyor?

Ancak, herkesi memnun edemezsiniz. Kişisel görüşüm ve konu hakkında konuştuğum kişilerin çoğunun görüşü, sorgu anlama sözdiziminin eşdeğer zorunlu sözdiziminden çok daha açık olduğu yönünde. Açıkça herkes kabul etmiyor, fakat neyse ki dil tasarımı yaparken milyonlarca müşterimizin fikir birliğine varmak zorunda değiliz.

Yine de "sezgisel" olan şey konusunda, birçok farklı dili inceleyen ve nihayet İngilizcenin tüm dillerin en iyisi olduğu sonucuna vardım çünkü İngilizcede kelimeler seninle aynı sırada geliyor . Onları düşün . Fransızların aksine, sürekli "köpek beyazı eti kırmızı yiyor" gibi şeyler söylüyorlar. O Fransız insanlar için ne kadar zor düşünmek kelimeleri doğru sırayla ve sonra zorunda söylemek onları Fransız sırayla! Fransızca çok sezgisel! Fransızların bunu konuşabilmesi inanılmaz. Ve almanca? "köpek eti yiyor" sanıyorlar ama sonra "etin yediği köpek" demek zorundalar!!!

Genellikle “sezgisel” olan şey yalnızca bir aşinalık meselesidir. Sorgularıma "select" cümlesiyle başlamayı bırakmadan önce LINQ ile çalışmam aylarca sürdü . Şimdi bu ikinci doğa ve SQL düzeni tuhaf görünüyor.

Hangisi! Kapsam belirleme kuralları SQL'de karışık. İş arkadaşınıza belirtmek isteyebileceğiniz bir şey, LINQ’un dikkatlice tasarlanmış olması (1) değişkenlerin ve kapsamların tanıtılması sağdan sola (*) ve (2) sorgunun sayfada göründüğü sıralamanın gerçekleşmesidir. yürütüldüğü sıra. Demek istediğin zaman

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

c solda kapsamda belirir ve sağda kapsamda kalır. Ve olayların gerçekleştiği sıra şöyledir: ilk “müşteriler” değerlendirilir. Daha sonra diziyi filtrelemek için "where" değerlendirilir. Ardından filtrelenmiş dizi "seç" ile yansıtılır.

SQL bu özelliğe sahip değildir. Eğer öyle diyorsan

SELECT Name FROM Customers WHERE City = 'London'

sonra "Ad", soluna değil sağa doğru bir şey tarafından kapsam içine alınır ve sorgu tamamen karışık bir sırada yürütülür; orta fıkra önce değerlendirilir, sonra son fıkra ve sonra ilk fıkra. Şimdilik çok uzun zamandır sadece LINQ ile çalışmış olmak bana çok tuhaf geliyor.

(*) Kapsam belirleme kuralları LINQ'da join cümlecikleri ile biraz garip. Ama bunun dışında, kapsamlar güzelce yuvalanır.

Programlama dünyasındaki herhangi bir şey gibi, sentaksıma alışmalısın ve sonra okumak (potansiyel olarak) daha kolaydır.

Programlama dünyasındaki herhangi bir şey gibi, spagetti kodu veya diğer suiistimaller için potansiyel var.

Programlama dünyasındaki herhangi bir şey gibi, bunu bu şekilde veya başka bir şekilde yapabilirsiniz.

Programlama dünyasındaki herhangi bir şey gibi, kilometreniz değişebilir.

LINQ / lambda ile ilgili olarak - "Bilgisayarınıza okunabilir değil, insanlara okunabilen bir kod yazın" ifadesiyle bir şeyler söylediği bir yorum / yorum gördüm.

Bununla birlikte, bu ifadenin çok fazla yararı olduğunu düşünüyorum; ancak, yüksek verimlilikli iş paralelinde paralel çözümler kullanarak, geliştirme, dilbilgisi, OO, yönetmenlik yoluyla, usule, OO aracılığıyla .

Çok sayıda farklı ticari sektörde üretim kalitesi sistemleri ve hizmetleri sunmak için kodumu olabildiğince okunaklı ve tekrar kullanılabilir hale getirme ve GOF tasarım model ilkelerinin çoğunu benimseme konusunda kendimden gurur duydum.

Lambda ifadesiyle ilk karşılaştığımda şöyle düşündüm: “Bu da neyin nesi!?!” Hemen tanıdık (ve dolayısıyla rahat) açık bildirimsel sözdizimine karşı sezgiseldi . Ancak , iş yerindeki genç <5 yaş genç , cennetten gelen adam gibi durdu!

Bunun nedeni yıllarca bir bilgisayar gibi düşünmenin (sözdizimsel anlamda) çok kolay bir şekilde doğrudan kodlama sözdizimine (dilden bağımsız olarak) çevrilmiş olmasıdır. Yaklaşık 20 + yıl boyunca (benim durumumda 30 +) bu hesaplama zihniyetine sahip olduğunuzda , lambda ifadesinin ilk sözdizimsel şokunun kolayca korku ve güvensizliğe dönüşebileceğini takdir etmeniz gerekir .

Belki OP'deki iş arkadaşı kendiminkine benzer bir arka plandan gelmişti (yani birkaç kez bloğun etrafında) ve o zaman onlar için karşı sezgiseldi? Sorum şu: bu konuda ne yaptınız? Eşdüzeyinizi satır içi sözdiziminin yararlarını anlama konusunda yeniden eğitmeye çalıştınız mı, yoksa "programla birlikte olmadığınız" için onları kandırdınız / dışladınız mı? İlki muhtemelen iş arkadaşınızın düşünce hattınıza geldiğini görecekti, ikincisi muhtemelen LINQ / lambda sözdizimini daha da güvensizleştirmelerini ve böylece olumsuz görüşü daha da kötüleştirmelerini sağlayacaktı.

Kendim için kendi düşünme tarzımı yeniden eğitmek zorunda kaldım (Eric yukarıda belirtildiği gibi, önemsiz bir zihin değişimi değil ve Miranda'da 80'lerde programlamak zorunda kaldım, bu yüzden işlevsel programlama deneyimimden payımı aldım) ama bir kez bu acıdan geçtim, faydalar açıktı - ama daha da önemlisi - kullanımının aşırı kullanıldığı (yani kullanımı uğruna kullanıldığı), karmaşık ve tekrarlayan (bu durumda DRY ilkesini göz önünde bulundurarak).

Hala çok fazla kod yazan ancak teknik olarak da çok fazla kod yazması gereken biri olarak, bu ilkeleri anlamam zorunluydu, böylece öğeleri tarafsız olarak gözden geçirebilirim, lambda ifadesinin kullanımının daha verimli olabileceğini tavsiye ederim. okunabilir ve ayrıca geliştiricilerin oldukça karmaşık satır içi lambda ifadelerinin okunabilirliğini göz önünde bulundurmasını sağlamak için (bir yöntem çağrısının - bu durumlarda - kodu daha okunaklı, sürdürülebilir ve genişletilebilir yapar).

Yani birileri "lambda alamadım" derken ya da LINQ sözdizimi, onları temelde yatan ilkeleri anlamalarına yardımcı olmak için bir luddite markası olarak kullanmak yerine . Sonuçta benim gibi bir "eski okul" geçmişine sahip olabilirler.

Lambda Expressions, sorguların çok uzun olması durumunda daha az okunabilir koda neden olur. Ancak çok fazla iç içe döngüden çok daha iyidir .

İkisinin karışımı ile daha iyi .

Daha hızlıysa (hızlı olması gerekiyorsa) veya okunması daha kolaysa Lambda'ya yazın.

Sanırım çoğu durumda (çok tuhaf bir şey yapmanın dışında), ne olup bittiğine dair bir fikir edinen kişi olarak "okunabilir" demek istediğinize ya da tüm küçük küçük ayrıntıları kolayca bulabileceklerine bağlı olduğunu düşünüyorum.

Bence link öncekilere yardımcı olur, fakat sıklıkla (özellikle hata ayıklama sırasında) ikinciye zarar verir.

IMHO, koda baktığımda, eski olanlara yabancı olduğumu biliyorum, ikincisinden çok daha önemli, bu yüzden onu çok daha okunaklı buluyorum.

LINQ sözdizimini sezgisel ve okunması kolay buluyorum, özellikle de FROM'u SQL'deki gibi ortada olmak yerine ait oldukları başlangıçta koydular. Ancak IMO lambdasları kafa karıştırıcıdır ve kodu okumayı zorlaştırır.

Linq sözdiziminin T-SQL'den önemli ölçüde farklı olmadığı konusunda size katılıyorum. İş arkadaşınız gerçekten onun güzel ve parlak OO kodunun karışmasına neden olan ilişkisel şeylere itiraz ediyor olabilir. Öte yandan, işlevsel programlama alışmak için biraz alıştırma ve buna alışmak için bir istek gerektirir.

Değişir. Açıkçası, T-SQL benzersiz bazı DB-ilişkisel çözümler sunar. Açıkçası LINQ benzersiz bir şekilde bazı OO çözümleri sunmaktadır.

Ancak; "T-SQL'den daha kafa karıştırıcı mı?" - ilk soruda tartışılır / sorulur. Bu, mevcut cevapların hiçbirinin adreslemediği bazı özellikleri açıkça ifade eder, bunun yerine geçmişte sıkışıp kalmış (açıkça tanınmış SQL) eleştirmenini suçlar.

Her ne kadar belirli nitelikler için LINQ’u takdir etsem ve buradaki mevcut cevaplara pek katılmasam da, karşı tarafın temsili hak ettiğini hissediyorum:

LINQ’ya aşina olduktan yıllar sonra, belirli grup işlemleri, dış birleştirmeler ve denk olmayanlar gerçekleştirme, bileşik tuşlarla çalışma ve LINQ’deki diğer işlemler beni hala zorluyor. (Özellikle performansa duyarlı sorularla ilişkisel bir arka uç hedeflerken.)

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

Bunun sezgisel olduğunu düşünüyorsanız, sizin için daha fazla güç. ;)

Muhtemelen Linq'un berbat olmasının bir nedeni vardır, bu ders kitabı örnekleri yerine gerçek dünya örnekleri yapmaya çalışın.

bu işlevi linqlamdathings'de göstermeye çalışın ve göreceksiniz ki, tüm güzellikler gitti, klasik yol okunaklı kalıyor. Ertelenmiş icra problemlerinden ve sınır değerlerin belirlenmesinden bahsetmiyorum bile.

Gerçek şu ki, LinqLambdaThings birkaç durumda çok yararlıdır ve sizin asla anlamadığınız tüm şık nesne yönelimini değiştirmeleri düşünülmez.

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