คุณต้องการความกระชับหรืออ่านง่ายในโค้ดของคุณหรือไม่? [ปิด]

ทางลัดภาษามักใช้เพื่อทำให้รหัสกระชับยิ่งขึ้น

ตัวอย่างเช่นตัวดำเนินการ ternary และ null รวมตัวกันสามารถลดจำนวนของโค้ดได้

ใน C #:

Person newGuy = new Person();
if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
} else {
    newGuy.Boss = boss;
}

มีหน้าที่เทียบเท่ากับ:

Person newGuy = new Person();
newGuy.Boss = boss ?? GetDefaultBoss();

แต่เห็นได้ชัดว่า verbose มากขึ้น

คุณจะวาดเส้นที่ไหนเมื่อมันมาถึงความกระชับและอ่านง่าย?

ทั้งสอง

ตัวอย่างแรกของคุณคือ verbose แน่นอนและชัดเจนมากขึ้น ... แต่ก็ยังต้องให้ฉันสแกนห้าบรรทัดแทนที่จะเป็นหนึ่ง เลวก็ deemphasizes วัตถุประสงค์ - newGuy.Bossการกำหนดค่าให้กับ

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

ตอนนี้ความคมชัดนี้:

if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
    newGuy.IsTemp = true;
    newGuy.AddTask("orientation");
} else {
    newGuy.Boss = boss;
    newGuy.IsTemp = false;
}

... ด้วย:

newGuy.Boss = boss ?? GetDefaultBoss();
newGuy.IsTemp = boss == null;
if ( boss == null ) newGuy.AddTask("orientation");

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

ในขณะที่ทั้งคู่เป็นเป้าหมายที่ดีฉันมักจะเข้าข้างกับความสามารถในการอ่านเมื่อถูกบังคับให้เลือก

ฉันขอยืนยันว่าตัวอย่างของคุณปรับปรุงทั้งความสามารถในการอ่านและความกระชับ พิจารณาอย่างไรก็ตาม:

if( a > b )
{
    foo = bar
}
else
{
    if( c.isThing() ){
        foo = somethingElse;
    }
    else{
        foo = someFurtherThing.GetFoo();
    }
}

ตรงข้ามกับ

foo = a > b ? bar ?? whatever.something : c.isThing() ? somethingElse : someFurtherThing.GetFoo();

อย่างหลังกระชับ แต่อ่านยาก อดีตคือ verbose แต่การไหลของตรรกะชัดเจน

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

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

ความกระชับและการอ่านไม่ตรงข้าม เช่นเดียวกับคำตอบนี้บางครั้งสั้นก็อ่านง่ายขึ้น

ฉันจะบอกว่าฉันชอบอ่าน แต่บางครั้งก็หมายถึงการใช้รหัสรัดกุม (คือประกอบไปด้วยเงื่อนไขที่ค่อนข้างง่ายภายในบล็อกที่มีเงื่อนไขขนาดใหญ่)

โดยทั่วไปถ้ามันยากที่จะเข้าใจโดยไม่จำเป็นอย่าทำ

ความสามารถในการอ่านเป็นอันดับแรกที่มันขัดแย้งกับความรัดกุมเนื่องจากโค้ดถูกแก้ไขบ่อยกว่าที่เขียนไว้ในตอนแรก ในทางกลับกัน:

1. สัญญาณรบกวนทางเสียงและรหัสสำเร็จรูปมักจะปิดบังความตั้งใจและทำให้อ่านง่าย บางครั้งรหัสที่สั้นกว่าก็สามารถอ่านได้มากขึ้นเช่นกัน ตัวอย่างเช่นคิดว่าฟังก์ชั่นแลมบ์ดาหรือผู้ได้รับมอบหมาย / ฟังก์ชั่นชั้นหนึ่งเมื่อเทียบกับชั้นเรียนวิธีเดียวที่ใช้อินเตอร์เฟซวิธีเดียว

2. ควรประเมินความสามารถในการอ่านโดยพิจารณาจากความง่ายในการอ่านรหัสสำหรับโปรแกรมเมอร์ที่มีประสบการณ์พอสมควรซึ่งรู้จักภาษาและคุณสมบัติที่เป็นเอกลักษณ์ / คุณสมบัติขั้นสูงค่อนข้างดี

แง่มุมหนึ่งที่ฉันไม่คิดว่ายังพูดถึง: เป้าหมายของคุณคืออะไร?

หากสิ่งที่คุณใส่ใจคือความปลอดภัยในการทำงานให้มองหาความรัดกุมและความกะทัดรัดเหนือสิ่งอื่นใด ข้ามความคิดเห็นรหัสของคุณเช่นกัน

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

_{^{หมายเหตุ: ข้างต้นไม่ได้เกี่ยวกับคุณเป็นการส่วนตัว @Damovisa; สำหรับทุกคนที่เลือกระหว่างสองตำแหน่ง}}

มีสิ่งหนึ่งที่รุ่น verbose เป็นข้อได้เปรียบ

มันมีเส้นมากขึ้นและนักแก้จุดบกพร่องส่วนใหญ่เป็นแบบเส้น ! มันยากมากที่จะกำหนดจุดพักในการแสดงออก

กล่าวอีกนัยหนึ่งคุณต้องการเห็นตัวแก้ไขแบบใดหากคุณต้องการให้ดีบั๊กเกอร์เริ่มทำงานเมื่อboss == nullใด

(นั่นบอกว่าฉันชอบตัวดำเนินการ ?? -)

การอ่านควรมาก่อนระยะยาวคนส่วนใหญ่ใช้เวลาส่วนใหญ่แก้ไขหรือขยายรหัสที่มีอยู่ - การอ่านเป็นส่วนใหญ่ของการบำรุงรักษา

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