C # อ่านยากขึ้นไหม

เมื่อ C # ได้รับการพัฒนาคุณสมบัติด้านภาษาจำนวนมากได้ถูกเพิ่ม มันมาถึงจุดที่มันกลายเป็นอ่านไม่ได้สำหรับฉัน

ยกตัวอย่างเช่นพิจารณารหัสต่อไปนี้จากรหัส Caliburn.Micro ที่นี่ :

            container = CompositionHost.Initialize(
                   new AggregateCatalog(
                      AssemblySource.Instance.
                             Select(x => new AssemblyCatalog(x))
                               .OfType<ComposablePartCatalog>()
                )
            );

ตอนนี้เป็นเพียงตัวอย่างเล็ก ๆ

ฉันมีคำถามจำนวนหนึ่ง:

• นี่เป็นปัญหาทั่วไปหรือเป็นที่รู้จักหรือไม่?
• ชุมชน C # ค้นหาเหมือนกันหรือไม่
• นี่เป็นปัญหาเกี่ยวกับภาษาหรือเป็นสไตล์ที่นักพัฒนาใช้หรือไม่

มีวิธีง่ายๆในการเข้าใจโค้ดอื่น ๆ และหลีกเลี่ยงการเขียนโค้ดด้วยวิธีนี้หรือไม่?

ทราบอย่างรวดเร็วในการที่ภาษาที่ควรจะชัดเจนขึ้น: C # เป็นภาษาโปรแกรมที่ใช้งานทั่วไป ; ซึ่งแตกต่างจาก C (เช่น C ++) มันมุ่งมั่นเพื่อให้เป็นนามธรรมสูง ซึ่งแตกต่างจากภาษา Lisp ที่มันมีจุดมุ่งหมายเพื่อการแสดงออกที่เป็นจริงและแตกต่างจาก Java มันเป็นแรงผลักดันมากขึ้น - Microsoft เป็นอย่างรวดเร็วเพื่อตอบสนองความต้องการ

นั่นคือเหตุผลที่มันกลายเป็นส่วนผสมของ LINQ, lambdas และคำหลักแปลกใหม่ - มันปรับตัวเข้ากับโดเมนปัญหาใหม่ได้อย่างรวดเร็วและนี่คือความลาดชันที่ลื่นไหลไปสู่ภาษาที่ซับซ้อนจนมีน้อยมากที่สามารถใช้ได้อย่างถูกต้อง (เช่น C ++) มันไม่ใช่ปัญหาของ C # แต่เป็นปัญหากับภาษาใด ๆ ที่มีเป้าหมายที่ทะเยอทะยานเหล่านี้

ชุมชนตระหนักถึงสิ่งนี้และที่สำคัญกว่านั้นคนที่อยู่เบื้องหลัง C # ได้ตระหนักถึงสิ่งนี้อย่างถี่ถ้วน (รายการบล็อกและพอดคาสต์สองสามรายการที่อยู่เบื้องหลังการเพิ่มใหม่ใน C # 5.0 แสดงให้เห็นว่า Microsoft กำลังพยายามโหลดบางส่วนออกจากเรือธงของพวกเขาเพื่อที่จะไม่กลายเป็น tarpit: การแนะนำของ DLR, สปอตไลท์ที่สดใสกว่าภาษาใหม่ (F #)

ยิ่งกว่านั้นเนื้อหาของหลักสูตรใน C # (รวมถึงการรับรอง MS) แนะนำรูปแบบการใช้ C # ที่แตกต่างกัน (แต่สอดคล้องกัน) ขึ้นอยู่กับปัญหา - เลือกอาวุธของคุณและติดมัน: LINQ สไตล์คล่องแคล่วในปัญหาบางอย่าง - เก่าแก่ที่สุด

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

ให้นำสองตัวอย่างทั้งสองตามตัวอย่างที่พบใน StackOverflow เกี่ยวกับปัญหาเดียวกันโดยการค้นหาประเภทที่มีแอตทริบิวต์เฉพาะ:

C # 2.0:

static IEnumerable<Type> GetTypesWithAttribute<TAttribute>(bool inherit) 
                              where TAttribute: System.Attribute
{
    foreach(Assembly assembly in AppDomain.Current.GetAssemblies())
    {
        foreach(Type type in assembly.GetTypes()) 
        {
            if (type.IsDefined(typeof(TAttribute),inherit))
                yield return type;
        }
    }
}

C # 4.0:

IEnumerable<Type> GetTypesWith<TAttribute>(bool inherit) 
                              where TAttribute: System.Attribute
{ 
    return from assembly in AppDomain.CurrentDomain.GetAssemblies()
           from type in assembly.GetTypes()
           where type.IsDefined(typeof(TAttribute),inherit)
           select type;
}

IMHO ไวยากรณ์ใหม่ทำให้อ่านง่ายขึ้นมาก

เมื่อเพิ่ม LINQ มันจะทำให้รูปแบบของการเข้ารหัสที่เกี่ยวข้องกับการผูกมัดวิธีการสไตล์ Fluent จำนวนมากและการส่งผ่านของ lambdas เป็นพารามิเตอร์

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

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

var assemblyCatalog = AssemblySource.Instance
    .Select(x => new AssemblyCatalog(x))
    .OfType<ComposablePartCatalog>();
var aggregateCatalog = new AggregateCatalog(assemblyCatalog);
container = CompositionHost.Initialize(aggregateCatalog);

รหัสในตัวอย่างของคุณไม่สามารถอ่านได้ง่ายเพราะ

• มันผสมผสานหลายแนวคิด (Composition, Catalogs, Aggregates, Assemblies, ComposableParts ... ) กับการซ้อนหลายระดับในขณะที่รหัสการโทรควรจะจัดการกับระดับเดียวเท่านั้น ดูเหมือนว่าเป็นการละเมิดกฎของ Demeter เท่านั้นด้วยการเรียกใช้เมธอดซ้อนแทนที่จะเป็นสายย่อยของคุณสมบัติย่อย นี่เป็นการรบกวนความตั้งใจที่อยู่เบื้องหลังบรรทัดของรหัสบ้าง

• มีการใช้งานซิงเกิลแปลก ๆ - AssemblySource.Instance.Select()หมายความว่าอินสแตนซ์เป็น IEnumerable ซึ่งค่อนข้างอึดอัดใจ

• ตัวแปร x ในนิพจน์แลมบ์ดานั้นน่าเกลียด โดยทั่วไปคุณพยายามให้แลมบ์ดาตัวแปรของคุณตั้งใจเปิดเผยชื่อ - ช่วยให้ผู้อ่านระบุประเภทของข้อมูลที่ใช้งานได้แม้ว่าเขาจะไม่คุ้นเคยกับแลมบ์ดาก็ตาม

• ยังไม่ชัดเจนว่าทำไมคุณควรกรองด้วยOfType<T>()ชุดของวัตถุที่คุณเพิ่งปรับใหม่ ...

อย่างไรก็ตามข้อบกพร่องเหล่านี้เกี่ยวข้องกับวิธีการที่นักพัฒนาดั้งเดิมเขียนรหัสและวิธีการที่เขาออกแบบให้เป็น นี่ไม่ใช่สิ่งที่เฉพาะเจาะจงสำหรับเวอร์ชันล่าสุดของ C # และลักษณะของแลมบ์ดานิพจน์

โดยทั่วไปแล้วจะช่วยในกรณีที่ผู้อ่านรหัสของคุณรู้ว่า lambdas ทำงานอย่างไร แต่ด้วยการตั้งชื่อที่ชัดเจนเพียงพอคุณเกือบจะจัดการเพื่อทำให้โค้ดของคุณสามารถอ่านได้แม้กับคนที่มีพื้นหลัง pre-.NET 3.5

เมื่อใดก็ตามที่ภาษายอดนิยมรุ่นใหม่ได้รับการสร้างใหม่การอภิปรายที่คล้ายกันก็จะเกิดขึ้น

ฉันยังมีข้อสงสัยเหล่านี้เมื่อหลายปีก่อน (http://gsscoder.blogspot.it/2009/08/use-csharps-features-wise.html)

ในความคิดของฉัน C # มีการพัฒนาในลักษณะที่สวยงามและสอดคล้องกัน

โค้ดในตัวอย่างของคุณไม่ซับซ้อนบางทีคุณอาจไม่ได้ใช้กับการแสดงออกแลมด้า

ปัญหาคือ C # ไม่เพียง แต่เป็นภาษาเชิงวัตถุเท่านั้นตอนนี้ยังรองรับโครงสร้างที่ใช้งานได้ (http://archive.msdn.microsoft.com/FunctionalCSharp/)

ฉันใช้เวลาซักครู่เพื่อทำความเข้าใจกับไวยากรณ์ของแลมบ์ดาและฉันมาจากภูมิหลังทางคณิตศาสตร์และฟิสิกส์ มันคล้ายกับการแสดงออกทางคณิตศาสตร์เล็กน้อยพวกเขาใช้ -> แทน =>:

ตัวอย่างคณิตศาสตร์ f (x): = x-> x + 2 สิ่งนี้อ่านเป็น "ฟังก์ชั่น f ของ x ถูกกำหนดให้เป็นแผนที่ x เพื่อ x + 2

c # example del myDelegate = x => x +2; สิ่งนี้อ่านว่า "myDelegate เป็นฟังก์ชั่นที่ myDelegate (x) แม็พ x on to x + 2

ความไม่ลงรอยกันระหว่างคณิตศาสตร์และการเขียนโปรแกรมไม่ได้ช่วยจริงๆแม้ว่าฉันคิดว่า -> ได้ถูกนำขึ้นใน C ++ ในฐานะ "คุณสมบัติของ" (urrgghh!)

http://en.wikipedia.org/wiki/List_of_mathematical_symbols