การใช้งาน LINQ และ Lambda Expressions นำไปสู่รหัสที่อ่านได้น้อยลงหรือไม่ [ปิด]

ฉันกำลังพูดคุยกับเพื่อนร่วมงานใน Linq ฉันจะคัดลอกที่นี่:

ผู้ร่วมงาน: ขอซื่อสัตย์ที่นี่ ไวยากรณ์ Linq แย่มาก มันสับสนและไม่ง่าย

ฉัน: โอ้มาเลยสับสนมากกว่า T-SQL เหรอ?

เพื่อนร่วมงาน: เอ่อใช่

ฉัน: มันมีส่วนพื้นฐานเดียวกันเลือกสถานที่และจาก

ผู้ร่วมงาน: Linq สำหรับฉันคือการกำจัดไอเท็มเชิงสัมพันธ์ + OO ผู้ร่วมงาน: อย่าเข้าใจฉันผิด - มันมีประสิทธิภาพอย่างไม่น่าเชื่อ แต่พวกเขาเรียกคืน SQL เพื่อใช้การเก็บรวบรวมวัตถุ agains

ฉันเห็นว่าการใช้ 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

สำหรับฉันนี่สะอาดและง่าย (อย่างน้อยง่ายกว่าทางเลือก) ในการอ่านคุณมีความคิดเห็นอย่างไรกับมัน?

ฉันไม่สามารถหาโพสต์ที่ถูกต้องอีกต่อไป แต่เอริค Lippert (และ softies อื่น ๆ อาจจะหลาย ๆ คน) ได้เห็นหลายต่อหลายครั้งเกี่ยวกับวิธี 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 แต่ไม่ได้พยายามในรูปร่างหรือรูปแบบใด ๆ ที่จะใช้แคลคูลัสเชิงสัมพันธ์ เป็นเพียงส่วนขยายที่ช่วยให้ค้นหาและเรียงลำดับโครงการได้ง่ายขึ้น "Query" ไม่ได้หมายถึง "relational" และในความเป็นจริงแล้วมีหลายฐานข้อมูลที่ไม่ใช่เชิงสัมพันธ์ที่ใช้ไวยากรณ์คล้าย SQL Linq เป็นอย่างหมดจดเชิงวัตถุมันก็เกิดขึ้นกับการทำงานร่วมกับฐานข้อมูลเชิงสัมพันธ์ผ่านกรอบเช่น Linq เพื่อ SQL เพราะบางวูดูต้นไม้แสดงออกและการออกแบบที่ชาญฉลาดจากทีมงาน C # ทำให้ฟังก์ชั่นที่ไม่ระบุชื่อโดยปริยายแปลงสภาพให้แก่ต้นไม้แสดงออก

ผู้ร่วมงาน: ขอซื่อสัตย์ที่นี่ ไวยากรณ์ Linq แย่มาก มันสับสนและไม่ง่าย

คุณไม่สามารถโต้เถียงกับคำวิจารณ์นั้นได้ สำหรับเพื่อนร่วมงานของคุณมันแย่มาก เราไม่สามารถออกแบบไวยากรณ์ที่ชัดเจนและใช้งานง่ายสำหรับพวกเขา นั่นคือความล้มเหลวของเราและคุณสามารถส่งคำขอโทษของฉันไปยังเพื่อนร่วมงานของคุณ ฉันยินดีที่จะให้คำแนะนำในการทำให้ดีขึ้น เพื่อนร่วมงานของคุณพบสิ่งใดเป็นพิเศษทำให้เกิดความสับสนหรือไม่เข้าใจง่าย

อย่างไรก็ตามคุณไม่สามารถทำให้ทุกคนพอใจได้ ความเห็นส่วนตัวของฉันและความเห็นของคนส่วนใหญ่ที่ฉันได้พูดคุยในเรื่องนี้ก็คือไวยากรณ์ของความเข้าใจในการสืบค้นนั้นชัดเจนกว่าไวยากรณ์ที่จำเป็นเทียบเท่า เห็นได้ชัดว่าไม่ใช่ทุกคนที่เห็นด้วย แต่โชคดีที่เราไม่ต้องการความเห็นเป็นเอกฉันท์จากลูกค้าหลายล้านคนของเราเมื่อเราออกแบบภาษา

ในเรื่องของ "สัญชาตญาณ" แม้ว่าฉันจะนึกถึงเรื่องราวของนักภาษาศาสตร์ชาวอังกฤษที่ศึกษาภาษาต่าง ๆ มากมายและในที่สุดก็ได้ข้อสรุปว่าภาษาอังกฤษเป็นภาษาที่ดีที่สุดของทุกภาษาเพราะในภาษาอังกฤษคำมาในลำดับเดียวกันกับคุณ พวกเขาคิดว่า ต่างจากชาวฝรั่งเศสที่พวกเขาพูดอย่างต่อเนื่องเช่น "สุนัขสีขาวกินเนื้อแดง" มันยากแค่ไหนที่คนฝรั่งเศสต้องคิดคำในลำดับที่ถูกต้องแล้วต้องพูดตามลำดับภาษาฝรั่งเศส ! ฝรั่งเศสใช้งานง่ายมาก! มันวิเศษมากที่คนฝรั่งเศสพูดได้ แล้วภาษาเยอรมันเหรอ? พวกเขาคิดว่า "สุนัขกินเนื้อ" แต่ต้องพูดว่า "สุนัขกินเนื้อ"!?!

บ่อยครั้งที่สิ่งที่ "ใช้งานง่าย" เป็นเพียงเรื่องของความคุ้นเคย ฉันใช้เวลาทำงานกับ LINQ หลายเดือนก่อนที่ฉันจะหยุดการสืบค้นด้วยประโยค "select" ตอนนี้มันเป็นลักษณะที่สองและคำสั่ง SQL ดูเหมือนแปลกประหลาด

ซึ่งมันคือ! กฎการกำหนดขอบเขตทั้งหมดนั้นเกิดความสับสนใน SQL สิ่งที่คุณอาจต้องการชี้ให้เห็นถึงผู้ร่วมงานคือ LINQ ได้รับการออกแบบอย่างระมัดระวังเพื่อให้ (1) การแนะนำตัวแปรและขอบเขตเกิดขึ้นจากซ้ายไปขวา (*) และ (2) ลำดับที่แบบสอบถามปรากฏบนหน้าคือ คำสั่งที่จะถูกดำเนินการ นั่นคือเมื่อคุณพูด

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

c จะปรากฏในขอบเขตทางด้านซ้ายและอยู่ในขอบเขตผ่านทางด้านขวา และลำดับของสิ่งต่าง ๆ ที่เกิดขึ้นคือ "ลูกค้า" คนแรกที่ถูกประเมิน จากนั้นจะทำการประเมิน "where" เพื่อกรองลำดับ จากนั้นลำดับการกรองจะถูกฉายโดย "เลือก"

SQL ไม่มีคุณสมบัตินี้ ถ้าคุณพูด

SELECT Name FROM Customers WHERE City = 'London'

จากนั้น "ชื่อ" จะถูกนำเข้ามาในขอบเขตโดยบางสิ่งทางด้านขวาไม่ใช่ทางซ้ายและแบบสอบถามจะถูกดำเนินการในลำดับที่ยุ่งเหยิงอย่างสมบูรณ์ ประโยคกลางจะถูกประเมินก่อนจากนั้นประโยคสุดท้ายและจากนั้นประโยคแรก ตอนนี้ดูเหมือนว่าจะบ้าและไม่ได้ใช้งานง่ายสำหรับฉันทำงานกับ LINQ มานานแล้ว

(*) กฎการกำหนดขอบเขตค่อนข้างแปลกใน LINQ พร้อมกับส่วนคำสั่ง แต่นอกเหนือจากนั้นขอบเขตรังอย่างดี

เช่นเดียวกับสิ่งอื่นใดในโลกแห่งการเขียนโปรแกรมคุณต้องคุ้นเคยกับไวยากรณ์แล้วอ่านง่ายขึ้น (อาจ)

เช่นเดียวกับสิ่งอื่น ๆ ในโลกแห่งการเขียนโปรแกรมมีความเป็นไปได้สำหรับสปาเก็ตตี้โค้ดหรือการใช้ในทางที่ผิดอื่น ๆ

เช่นเดียวกับสิ่งอื่นใดในโลกแห่งการเขียนโปรแกรมคุณสามารถทำได้ด้วยวิธีนี้หรืออีกวิธีหนึ่ง

เช่นเดียวกับสิ่งอื่นใดในโลกแห่งการเขียนโปรแกรมไมล์สะสมของคุณอาจแตกต่างกันไป

ฉันเห็นความคิดเห็น / ข้อสังเกตซึ่งระบุบางสิ่งบางอย่าง - ที่เกี่ยวข้องกับ LINQ / แลมบ์ดา - ตามแนวของ: "เขียนโค้ดที่อ่านได้สำหรับมนุษย์แทนที่จะอ่านบนคอมพิวเตอร์ของคุณ"

ฉันคิดว่าคำแถลงนี้มีข้อดีมากมาย แต่ให้พิจารณาผู้พัฒนา (เช่นตัวฉันเอง) ที่ผ่านช่วงการพัฒนาภาษาจาก Assembly ผ่านขั้นตอนผ่าน OO ผ่านการจัดการผ่านการจัดการภาระงานสูง .

ฉันภูมิใจในการสร้างรหัสของฉันให้อ่านได้และนำมาใช้ซ้ำได้มากที่สุดและใช้หลักการรูปแบบการออกแบบ GOF จำนวนมากเพื่อส่งมอบระบบและบริการคุณภาพการผลิตในภาคธุรกิจที่แตกต่างกันจำนวนมาก

ครั้งแรกที่ฉันพบแลมบ์ดานิพจน์ฉันคิดว่า: "นั่นมันอะไรกันเนี่ย!?!" มันเป็นไวยากรณ์ที่ชัดเจนที่คุ้นเคย (และสะดวกสบาย) ของฉันในการตอบโต้ทันที อายุน้อยกว่า 5 ปีในกลุ่มงานแต่กระหน่ำมันเหมือนมานาจากสวรรค์!

นั่นเป็นเพราะหลายปีที่คิดเช่นเดียวกับคอมพิวเตอร์ (ในแง่ของคำศัพท์) แปลได้ง่ายมากในรูปแบบการเข้ารหัสโดยตรง (โดยไม่คำนึงถึงภาษา) เมื่อคุณมีความคิดว่าการคำนวณสำหรับประมาณ 20 ปี + (30 + ในกรณีของฉัน) คุณต้องชื่นชมว่าประโยคเริ่มต้นช็อตของการแสดงออกแลมบ์ดาสามารถแปลเป็นความกลัวและความไม่ไว้วางใจ

บางทีเพื่อนร่วมงานใน OP อาจมาจากภูมิหลังที่คล้ายกันกับตัวเอง (เช่นอยู่รอบบล็อกสองสามครั้ง) และมันก็ตอบโต้พวกเขาได้ง่ายในเวลานั้น? คำถามของฉันคือคุณทำอะไรกับมัน คุณพยายามให้ความรู้แก่เพื่อนของคุณอีกครั้งเพื่อทำความเข้าใจเกี่ยวกับประโยชน์ของไวยากรณ์แบบอินไลน์หรือคุณประจาน / เนรเทศพวกเขาโดยไม่ "อยู่กับโปรแกรม" หรือไม่? อดีตอาจจะเห็นเพื่อนร่วมงานของคุณมาถึงแนวความคิดของคุณหลังอาจทำให้พวกเขาไม่ไว้วางใจไวยากรณ์ LINQ / แลมบ์ดามากยิ่งขึ้นและทำให้ความคิดเห็นเชิงลบเลวร้ายยิ่งขึ้น

สำหรับตัวฉันเองฉันต้องรู้วิธีคิดของตัวเองอีกครั้ง (อย่างที่เอริค infers ข้างต้นมันไม่เปลี่ยนความคิดที่ไม่มีนัยสำคัญและฉันต้องเขียนโปรแกรมในมิแรนดาในยุค 80 ดังนั้นฉันจึงมีส่วนร่วมในการเขียนโปรแกรม แต่เมื่อฉันได้รับความเจ็บปวดนั้นประโยชน์ก็ชัดเจน แต่ที่สำคัญกว่านั้นคือการใช้งานอย่างแพร่หลาย (เช่นใช้เพื่อประโยชน์ในการใช้) มากกว่าที่ซับซ้อนและซ้ำซ้อน (พิจารณาหลักการ DRY ในตัวอย่างนั้น)

ในฐานะที่เป็นคนที่ไม่เพียง แต่ยังคงเขียนรหัสจำนวนมาก แต่ยังมีการตรวจสอบทางเทคนิคของรหัสจำนวนมากมันเป็นสิ่งจำเป็นที่ฉันเข้าใจหลักการเหล่านี้เพื่อให้ฉันสามารถตรวจสอบรายการที่เป็นกลางแนะนำการใช้แลมบ์ดาแสดงออก สามารถอ่านได้และเพื่อให้ผู้พัฒนาพิจารณาถึงความสามารถในการอ่านนิพจน์แลมบ์ดาแบบอินไลน์ที่ซับซ้อนสูง (ซึ่งการเรียกเมธอดจะ - ในกรณีเหล่านี้ - ทำให้โค้ดอ่านได้ง่ายขึ้นสามารถบำรุงรักษาได้และขยายได้)

ดังนั้นเมื่อมีคนบอกว่าพวกเขา "ไม่ได้แลมบ์ดา" หรือไวยากรณ์ LINQ แทนที่จะเป็นแบรนด์ludditeพยายามช่วยให้พวกเขาเข้าใจหลักการพื้นฐาน พวกเขาอาจมีพื้นหลัง "โรงเรียนเก่า" เช่นตัวเอง

แลมบ์ดานิพจน์ทำให้รหัสที่อ่านได้น้อยลงหากข้อความค้นหายาวเกินไป แต่มันจะดีกว่ามากเกินไปลูปซ้อนกัน

จะดีกว่าที่มีส่วนผสมของทั้งสอง

เขียนในแลมบ์ดาถ้ามันเร็วกว่า (คุณต้องใช้ให้เร็ว) หรืออ่านง่ายขึ้น

ฉันคิดว่ามันขึ้นอยู่กับกรณีส่วนใหญ่ (ยกเว้นเมื่อทำสิ่งที่แปลกประหลาดมาก) ถ้าคุณหมายถึง "อ่าน" เป็นคนที่ได้รับความคิดของสิ่งที่เกิดขึ้นหรือถ้าพวกเขาสามารถหารายละเอียดเล็ก ๆ น้อย ๆ ได้อย่างง่ายดาย

ฉันคิดว่าลิงก์ช่วยในอดีต แต่บ่อยครั้ง (โดยเฉพาะเมื่อแก้ไขข้อบกพร่อง) เจ็บหลัง

IMHO เมื่อฉันดูรหัสฉันไม่คุ้นเคยกับอดีตมีความสำคัญมากกว่าสมัยก่อนดังนั้นฉันจึงพบว่าอ่านง่ายกว่ามาก

ฉันพบว่าไวยากรณ์ LINQ ใช้งานง่ายและอ่านง่ายโดยเฉพาะอย่างยิ่งเนื่องจากวาง FROM ตั้งแต่เริ่มต้นซึ่งเป็นเจ้าของแทนที่จะอยู่ตรงกลางเหมือนใน SQL แต่ลูกแกะของ IMO นั้นสับสนและทำให้อ่านรหัสยากขึ้น

ฉันเห็นด้วยกับคุณว่าไวยากรณ์ Linq ไม่แตกต่างจาก T-SQL อย่างมีนัยสำคัญ ฉันคิดว่าเพื่อนร่วมงานของคุณอาจจะไม่พอใจกับสิ่งที่สัมพันธ์กันมากขึ้นซึ่งรหัส OO ที่ดีและเป็นประกายของเขา ในทางกลับกันการเขียนโปรแกรมที่ใช้งานได้ใช้เวลาเล็กน้อยในการทำความคุ้นเคยและความเต็มใจที่จะทำความคุ้นเคย

มันขึ้นอยู่กับ. เห็นได้ชัดว่า T-SQL มีโซลูชัน DB-relational บางส่วนที่ไม่ซ้ำกัน เห็นได้ชัดว่า LINQ มอบโซลูชั่น OO บางอย่างโดยเฉพาะ

อย่างไรก็ตาม; "สับสนมากกว่า T-SQL เหรอ?" - ถูกกล่าวถึง / ถามในคำถามเริ่มต้น นี่แสดงให้เห็นอย่างชัดเจนถึงฟีเจอร์บางอย่างที่ไม่มีคำตอบที่มีอยู่แทนที่จะกล่าวหานักวิจารณ์ (ที่รู้จักกันอย่างชัดเจนใน SQL) แทนที่จะติดอยู่ในอดีต

ดังนั้นแม้ว่าฉันจะขอขอบคุณ LINQ สำหรับคุณสมบัติบางอย่างและไม่เห็นด้วยอย่างยิ่งกับคำตอบที่มีอยู่ที่นี่ แต่ฉันรู้สึกว่าจุดคู่ควรที่จะเป็นตัวแทน:

หลายปีหลังจากคุ้นเคยกับ LINQ การปฏิบัติงานกลุ่มบางอย่างการรวมภายนอกและไม่ equijoins การทำงานกับคีย์ผสมและการดำเนินการอื่น ๆ ใน 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;
    }