ข้อห้ามในการใช้ลูปภายในลูปคืออะไร

แค่สงสัย. สิ่งที่ฉันเคยมีมากที่สุดคือสำหรับวงในสำหรับวงเนื่องจากหลังจากอ่านบทความนี้จากLinus Torvalds:

แท็บคือ 8 ตัวอักษรและทำให้การเยื้องเป็น 8 ตัวอักษร มีการเคลื่อนไหวนอกรีตที่พยายามทำการเยื้อง 4 (หรือแม้แต่ 2!) ตัวละครที่ลึกและคล้ายกับการพยายามกำหนดค่าของ PI ให้เป็น 3

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

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

https://www.kernel.org/doc/Documentation/CodingStyle

ฉันคิดว่ามันเป็นวิธีปฏิบัติที่ยอมรับไม่ได้สำหรับฉันที่จะไปที่เลเยอร์ที่สามของการวนซ้ำและจะปรับโครงสร้างรหัสของฉัน (เบื้องต้น Qt)

Linus พูดเล่นหรือเปล่า

มันขึ้นอยู่กับภาษาหรือแอพพลิเคชั่นหรือไม่?

มีบางสิ่งที่จำเป็นต้องวนซ้ำอย่างน้อยสามระดับหรือไม่

เคอร์เนลขอแนะนำอัลกอริธึมอย่างง่าย

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

นอกจากนี้ลินุกซ์เคอร์เนลจะแตกต่างจากรหัสใบสมัครมากที่สุดสำหรับความต้องการของการตรวจสอบแบบและการทดสอบ - จึงต้องการที่จะไม่ได้มีระดับ 4+ อัลกอริทึมที่ซ้อนกันในฟังก์ชั่นเดียว มันควรจะเป็นที่ชัดเจนที่จะเห็นสิ่งที่แต่ละรหัสส่วนไม่ว่าและในรายละเอียดรวมทั้งการควบคุมการไหลและขอบที่เป็นไปได้ทุกกรณี รหัสที่ซ้อนกันอย่างลึกซึ้งนั้นเป็นอุปสรรค

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

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

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

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

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

Linus พูดเล่นหรือเปล่า

ชิ้นส่วนถูกเขียนในสไตล์ขี้เล่นซึ่งแสดงให้เห็นว่าผู้เขียนมีความคุ้นเคยกับวิธีการเขียนโค้ดที่ถูกกล่าวถึงในหมู่ผู้ปฏิบัติงานที่จริงจัง: เราทุกคนมีความพึงพอใจของเราและเราปกป้องพวกเขาอย่างบ้าคลั่ง เราเข้าใจดีอย่างสมบูรณ์ว่าส่วนใหญ่เป็นเพียงเรื่องของรสนิยมส่วนตัว เขากล่าวว่าในหลาย ๆ คำ"Coding style is very personal, and I won't _force_ my views on anybody"อย่างน้อยนอกรหัสที่เขารักษาไว้เป็นการส่วนตัว แต่ความสอดคล้องของสไตล์ในโครงการที่กำหนดเป็นความคิดที่ดีมาก ฉันต้องการเขียนโค้ดให้เป็นสไตล์ที่ฉันไม่ชอบมากกว่าจัดการกับสไตล์ที่หลากหลายในฟังก์ชั่นที่กำหนด

นี่คือตัวอย่างของการเขียนที่ขี้เล่นอย่างชัดเจน:

However, there is one special case, namely functions: they have the
opening brace at the beginning of the next line, thus:

int function(int x)
{
    body of function
}

Heretic people all over the world have claimed that this inconsistency
is ...  well ...  inconsistent, but all right-thinking people know that
(a) K&R are _right_ and (b) K&R are right.  Besides, functions are
special anyway (you can't nest them in C).

ขี้เล่น (1)

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

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

หากคุณพบเจอใครบางคนบนอินเทอร์เน็ตที่คิดว่าเขาเข้าใจการเขียนโปรแกรมดีกว่า Torvalds (2) คุณก็รู้ว่าคนประเภทไหนที่ชอบคุยเรื่องใหญ่บนอินเทอร์เน็ต

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

(1) แต่ให้สังเกตว่าเขาวางช่องว่างไว้ตรงหน้าวงรีและช่องว่างสองช่องหลังจากนั้นและช่องว่างสองช่องหลังจากหยุดเต็ม ผิด, ผิด, ผิด จากนั้นเขาก็มีถุงน้ำดีที่ทำหน้าที่เป็นคนนอก คนนอกรีตคือคุณ Torvalds! มันคือคุณ!

(2) ถ้าคุณต้องการพูดคุยเกี่ยวกับ "การทำความเข้าใจวิธีการออกแบบระบบควบคุมแหล่งที่มา " อาจมีบางห้องสำหรับการอภิปราย

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

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

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

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

การซ้อนที่มากเกินไปเป็นหนึ่งในกรณีที่ง่ายต่อการเขียน แต่อ่านยากขึ้น การตั้งค่าความลึกแท็บขนาดใหญ่เป็นวิธีของ Linus ที่ทำให้การเขียนน่ารำคาญยิ่งขึ้น

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

เรื่องนี้ดูเหมือนจะเป็นกรณีตำราของหางกระดิกสุนัข

หากคุณมีการแสดงผล 80 ตัวอักษรแน่นอนว่าคุณกำลังพยายามทำโค้ดให้พอดีที่สุดเท่าที่จะทำได้แม้ว่ามันจะไม่ได้สร้างโครงสร้างที่ดีที่สุดสำหรับโค้ดก็ตาม

การแก้ปัญหาส่วนที่เหลือของคะแนนของคุณมุ่งไปที่:

ฉันคิดว่ามันเป็นการปฏิบัติที่ยอมรับไม่ได้

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

เขาล้อเล่นไหม?

ยากที่จะตรวจสอบบริบท แต่เห็นจุดเดิมของฉันข้างต้น

มันขึ้นอยู่กับภาษาหรือแอพพลิเคชั่นหรือไม่?

เป็นอย่างมาก ใช้ภาษาเมนเฟรม / ระดับกลางใด ๆ ที่คุณมีโอกาสเข้ารหัสบนเทอร์มินัล (หรือเทอร์มินัลอีมูเลเตอร์)

มีบางสิ่งที่จำเป็นต้องวนซ้ำอย่างน้อยสามระดับหรือไม่

ใช่มันเป็นเรื่องธรรมดามากในอัลกอริทึมกำลังดุร้ายบางอย่าง ดูที่ปัญหา 31เกี่ยวกับ Project Euler นี่เป็นตัวอย่างคลาสสิกของปัญหาที่สามารถแก้ไขได้ด้วยกำลังดุร้ายโดยใช้ลูปจำนวนหนึ่ง (8 เป็นค่าที่แน่นอน)

Linus พูดเล่นหรือเปล่า

ไม่ได้นั่นคือแนวทางปฏิบัติราชการ

มันขึ้นอยู่กับภาษาหรือแอพพลิเคชั่นหรือไม่?

โดยทั่วไปแนวทางการเข้ารหัสขึ้นอยู่กับภาษาและแอปพลิเคชันอย่างไรก็ตามรหัสที่ซ้อนกันอย่างล้ำลึกจะเก็บภาษีผู้อ่านเสมอ

ปัญหาเกี่ยวกับรหัสที่ซ้อนกันคือโดยทั่วไปแล้วจะเพิ่มความซับซ้อนของวงจร: นั่นคือยิ่งรหัสที่ซ้อนกันมากเท่าไหร่ก็จะมีเส้นทางการดำเนินการที่เป็นไปได้มากขึ้นภายในฟังก์ชัน การระเบิดด้วย combinatorial ของเส้นทางการประมวลผลที่เป็นไปได้ทำให้มันยากที่จะให้เหตุผลเกี่ยวกับรหัสและดังนั้นควรหลีกเลี่ยงโดยทั่วไป

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

มันเป็นกฎเกณฑ์และเพียงพอสำหรับพวกเขา

มีบางสิ่งที่จำเป็นต้องวนซ้ำอย่างน้อยสามระดับหรือไม่

อัลกอริทึมฉลาด แต่ในภาษาที่แสดงออกอย่างเพียงพอคุณสามารถ refactor รหัสเป็นชิ้นเล็ก ๆ (ไม่ว่าจะมีฟังก์ชั่นหรือปิด)

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

... อย่างไรก็ตามฟังก์ชั่นขนาดเล็กที่มีสัญญาที่ชัดเจนนั้นง่ายต่อการตรวจสอบมากกว่าฟังก์ชั่นขนาดใหญ่ที่มีสัญญาที่ชัดเจนโดยทั่วไป