อะไรคือความแตกต่างระหว่างสไตล์ K&R และหนึ่งสไตล์ทรูรั้ง (1TBS)?

ฉันได้อ่านบทความ Wikipedia เกี่ยวกับรูปแบบการเยื้องแล้ว แต่ฉันยังไม่เข้าใจ K&R และ 1TBS แตกต่างกันอย่างไร?

ความแตกต่างที่ใหญ่ที่สุดระหว่าง K & R และทรูรั้ง Style One (1TBS) ที่อยู่ใน 1TBS ทั้งหมดif, else, whileและforงบมีการเปิดและปิดวงเล็บแม้ว่าพวกเขาจะไม่จำเป็น วัตถุประสงค์คือเพื่อทำให้ง่ายต่อการแทรกคำสั่งใหม่และรู้ว่าพวกเขาจะจัดกลุ่มอย่างไร

ตัวอย่างเช่น:

K & R:

int i;
for (i = 0; i < 10; i++)
  printf("Hi.");

1TBS:

int i;
for (i = 0; i < 10; i++) {
  printf("Hi");
}

K&R เป็นเช่นนี้:

if (x) 
    a();
else {
    b();
    c();
}

นั่นคือ: วงเล็บปีกกาใช้เฉพาะเมื่อจำเป็นเท่านั้นเปิดวงเล็บปีกกาในบรรทัดเดียวกับคำสั่งควบคุมปิดวงเล็บปีกกาในบรรทัดของมันเอง

"หนึ่งในวงเล็บปีกกาสไตล์ที่แท้จริง" (1TBS หรือ OTBS) เปลี่ยนคำสั่งควบคุมเดียวเป็นคำสั่งผสมโดยการใส่ไว้ในวงเล็บปีกกา:

if (x) {
    a();
} else {
    b();
    c();
}

สไตล์ Allman ไปไกลกว่า 1TBS เล็กน้อยและบังคับให้เว้นวรรคในแนวตั้งโดยวางรั้งช่องเปิดไว้บนเส้นด้วยตัวเองเช่นกัน:

if (x) 
{
    a();
}
else 
{
    b();
    c();
}

แก้ไข:

ฉันยังคงพยายามหาว่ามันมีคุณสมบัติอย่างไรในฐานะ "หยิ่ง" ที่จะพูดว่า "เดนนิสริตชี่เป็นคนฉลาดมากที่ไม่เพียง แต่คิดค้นภาษาที่ดีเท่านั้น

สำหรับผู้ที่ยืนยันว่ามันหยิ่งอยู่ต่อไปนี่เป็นความท้าทายเล็กน้อย: ไปที่ Sourceforge, Github (ฯลฯ ) และเลือกโครงการโดยใช้รูปแบบการรั้ง K&R ผ่านการบันทึกข้อบกพร่องและการกระทำของพวกเขาและพยายามที่จะหาข้อผิดพลาดเดียวที่เกิดจากสไตล์รั้งพวกเขาใช้

หากคุณไม่ต้องการทำงานให้ลองวิเคราะห์สถิติอย่างง่าย เปรียบเทียบโครงการที่ใช้รูปแบบวงเล็บปีกกาที่แตกต่างกันและดูว่าคุณสามารถแสดง "bimodality" - ความแตกต่างอย่างมีนัยสำคัญทางสถิติในการนับข้อผิดพลาด (ความรุนแรง ฯลฯ ) ที่มีความสัมพันธ์กับสไตล์การค้ำยัน

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

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

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

ปัญหาโดยทั่วไปที่มีรูปแบบ KR รั้งอยู่ในการปรับโครงสร้างรหัส เมื่อย้ายโค้ดไปรอบ ๆ มันเป็นเรื่องง่ายที่จะพลาดว่าไม่มีวงเล็บปีกกาบางสิ่งบางอย่างย้ายอย่างไม่ถูกต้อง (หรือย้ายบางสิ่งบางอย่างภายใต้มันคิดว่ามันถูกดำเนินการตามเงื่อนไข) และจากนั้นเกาหัวของคุณเมื่อบางสิ่งบางอย่างไม่ทำงาน พื้นที่โค้ดไม่ได้รับการทดสอบอย่างดีและข้อผิดพลาดเกิดขึ้นโดยไม่มีใครสังเกตจนกว่าหมวกสีดำจะหาวิธีในการใช้ประโยชน์จากมัน ทริปด่วนเข้าสู่เครื่องมือดีบั๊กจะพบปัญหาหากคุณสังเกตเห็น แต่ถ้าคุณไม่ ...