แนวทางการเข้ารหัส: วิธีการไม่ควรมีคำสั่งมากกว่า 7 รายการ?

ฉันกำลังดูแนวทางการเข้ารหัสของ AvSolสำหรับ C # และฉันเห็นด้วยกับเกือบทุกอย่าง แต่ฉันอยากรู้จริง ๆ ว่าคนอื่นคิดอย่างไรกับกฎข้อหนึ่ง

AV1500

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

คุณส่วนใหญ่ปฏิบัติตามกฎนี้หรือไม่? แม้ว่าจะมีน้อยที่จะถูกบันทึกจากการสร้างวิธีการใหม่ (รหัสของคุณยังคงแห้ง ) นอกเหนือจากการอ่านที่เพิ่มขึ้นอย่างมาก? และหมายเลขของคุณยังต่ำอยู่ที่ 7 หรือไม่ ฉันจะมีแนวโน้มมากขึ้นต่อ 10

ฉันไม่ได้บอกว่าฉันละเมิดกฎนี้ทั่วทุกที่ - ในทางตรงกันข้ามวิธีการของฉันเล็ก 95% และเน้น แต่บอกว่าคุณไม่ควรละเมิดกฎนี้จริงๆพัดฉันออกไป

ฉันแค่อยากจะรู้ว่าสิ่งที่ทุกคนคิดว่าไม่เคยละเมิดกฎนี้ (มัน '1' ในมาตรฐานการเข้ารหัส - ความหมายไม่เคยทำเช่นนี้) แต่ฉันคิดว่าคุณมีปัญหาในการค้นหา codebase ที่ไม่ได้

นี่คือ "กลิ่นมาตรฐาน" สำหรับฉัน เมื่อใดก็ตามที่ฉันเห็นมาตรฐานการเข้ารหัสที่มีข้อ จำกัด เฉพาะในพวกเขาฉันกังวล คุณมักจะพบกับกรณีที่เมธอดจำเป็นต้องมีขนาดใหญ่กว่ามาตรฐานที่อนุญาต (ไม่ว่าจะเป็นความยาว / จำนวนบรรทัด, จำนวนตัวแปร, จำนวนจุดออก ฯลฯ ) มาตรฐานควรเป็นแนวทางมากกว่าและอนุญาตให้มีเวลาเพียงพอสำหรับการใช้วิจารณญาณที่ดี อย่าเข้าใจฉันผิดมันเป็นการดีที่จะมีมาตรฐาน แต่พวกเขาไม่ควรกลายเป็น

มันเป็นความคิดที่ดีที่จะแบ่งสิ่งต่าง ๆ เป็นวิธีเล็ก ๆ น้อย ๆ แต่สิ่งสำคัญคือการแยกสิ่งที่มันสมเหตุสมผล

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

Steve McConnellระบุไว้ในCode Completeว่าคุณไม่ได้มีประสิทธิภาพมากขึ้นเมื่อใช้วิธีการแบบสั้น หากคุณแยกเมื่อไม่เหมาะสมคุณจะเพิ่มความซับซ้อนให้กับโค้ดโดยไม่มีประโยชน์

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

ควรถือว่าเป็นกฎง่ายๆ

สิ่งต่าง ๆ เช่น "คอลัมน์ข้อความไม่เกิน 80 (100,120)", "ทางออกเดียวต่อวิธี", "ไม่เกิน 2 ระดับของการทำรัง" คือสิ่งที่ฉันจะเรียกเกณฑ์สำหรับตัวบ่งชี้ของกลิ่นรหัส หากคุณละเมิดพวกเขาในบางครั้งนั่นไม่ได้หมายความว่ารหัสนั้นไม่ดี หากคุณพบว่าตัวเองละเมิดพวกเขาอย่างสม่ำเสมอมีบางสิ่งที่มีกลิ่นในรหัสและคุณอาจต้องการหยุดชั่วคราวและทบทวนวิธีการของคุณใหม่

สำหรับฉันเกณฑ์ที่สำคัญที่สุดคือ "รหัสนี้เป็นที่เข้าใจได้หรือไม่", "มันซ้ำซ้อนหรือไม่", "มันเสียในที่ตรรกะหรือไม่?", "มันเป็นคู่ที่หลวมหรือเปล่า" มีอีกไม่กี่อย่าง แต่ฉันคิดว่าแนวคิดพื้นฐานสามารถสรุปได้โดยการจดจำคำแนะนำของ Donald Knuth: "โปรแกรมนั้นมีไว้สำหรับมนุษย์และสามารถอ่านได้โดยไม่ตั้งใจเท่านั้น"

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

มันเป็นค่าประมาณ

กฎเหล่านี้ไม่ควรนำมาใช้อย่างแท้จริง พวกเขาอาจพูดว่า " วิธีการควรสั้น " อย่างไรก็ตามบางคนอาจตีความว่าเป็น "น้อยกว่า 1 หน้า" และอื่น ๆ เป็น "มากที่สุด 2 บรรทัด"

ฉันจะสมมติว่าพวกเขาพูดว่า "7 statement" เพื่อให้ความคิดคร่าวๆกับคุณ (แม้ว่าฉันคิดว่าพวกเขาควรจะพูดว่า "ประมาณ 7") หากคุณต้องการ 9 ครั้งในขณะที่ไม่เหงื่อออก แต่ถ้าคุณกด 20 คุณจะรู้ว่าคุณไม่ได้อยู่ใน ballpark ที่เหมาะสมสำหรับกฎนี้

7 เป็นตัวเลขที่ไม่มีกฎเกณฑ์ใด ๆ เลย

ความซับซ้อนของวงจรเป็นปัญหาใหญ่กว่าจำนวนงบ ฉันเห็นโค้ดที่มีข้อความ 100 ข้อความในวิธีการเดียว (ซึ่งฉันคิดว่าแย่มาก) แต่มันมีความซับซ้อนตามวัฏจักรของ 1 และมันก็แค่ 1 อย่างเท่านั้น มีเพียงขั้นตอนมากมาย เราได้พูดถึงการแบ่งมันออกเป็นวิธีที่เล็กกว่า แต่วิธีเหล่านั้นจะถูกเรียกโดยวิธีนี้เพียงวิธีเดียว

ในขณะที่เป็นกรณีที่ค่อนข้างรุนแรงประเด็นคือคุณต้องเก็บรหัส DRY และความซับซ้อนของวงจรต่ำ นั่นสำคัญกว่าจำนวนบรรทัดในเมธอด

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

การทำลายโค้ดอย่างผิด ๆ เป็นวิธีการอื่น ๆ เพียงเพื่อให้จำนวนงบต่ำกว่า 7 เพียงทำให้โค้ดของคุณแย่ลง

แนวทางควรเป็นแต่ละวิธีควรทำ 1 สิ่งและเก็บรหัสของคุณไว้

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

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

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

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

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

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

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

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

สรุป? หากเปรียบเทียบกลิ่นการออกแบบของ "ใช้ข้อความน้อยกว่า 7 ข้อความ" กับกลิ่นรหัสของ "ฉันใช้ข้อความมากกว่า 7 ข้อความ" ฉันควรกำจัดกลิ่นรหัสออกไป

ว้าว! ฉันไม่เคยคาดหวังว่าจะพบการสนทนาที่เข้มข้นเช่นนี้ในแนวทางง่าย ๆ ที่บอกว่าวิธีการของคุณควรมีขนาดเล็กมาก เนื่องจากพวกเขาเป็นนักพัฒนาซอฟต์แวร์ที่ต้องการให้แนวทางของพวกเขาชัดเจนฉันเลือก 7 เพราะฟังดูดีกว่า

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

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

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

ประการแรก: มันเป็นแนวทางไม่ใช่กฎ มันเรียกว่าแนวทางดังนั้นโปรดปฏิบัติเช่นนี้ นี่ก็หมายความว่าคุณต้องมีการตัดสินใจด้วยตนเอง (เช่นเคย)

นอกเหนือจากนั้นฉันสามารถนึกถึงตัวอย่างของรหัสที่ดีมากมายที่ไม่เป็นไปตามข้อ จำกัด นี้ แม้ว่าจะเป็นเพียงแนวทาง แต่ก็เป็นแนวทางที่ไม่ดี

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

ค่อนข้างโง่เมื่อคุณเพิ่มการจัดการข้อยกเว้นลงในส่วนผสม

หลังจาก "ลองจับแล้วในที่สุด" คุณเหลือคำสั่งสี่รายการต่อวิธี!

นอกจากนี้ให้พิจารณาเมธอด "validateForm" สำหรับฟอร์มฟิลด์ 20 แม้ว่าคุณจะจัดการกับการตรวจสอบแต่ละรายการทั้งหมดในวิธีที่แยกต่างหากคุณยังมีวิธีตรวจสอบฟิลด์ 20 วิธีที่จะเรียกใช้ ตามแนวทางเหล่านี้คุณจะพบกับการแบ่งที่ไม่มีจุดหมายเช่น "validateTopOfScreen", "validateMiddleOfScreen" และ "validateBottomOfScreen"

คำถามกำลังทำให้เกิด "กฎ" กับ "แนวทาง" กฎมีไว้เพื่อให้เชื่อฟัง - แนวทางคือคำแนะนำที่มีไว้เพื่อให้คุณพิจารณาสิ่งที่คุณกำลังทำและหากสามารถทำได้จริง ๆ ในทางที่ดีขึ้น

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

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

ฉันเห็นด้วยกับความคิดเห็นข้างต้น 7 สำหรับฉันเป็นตระกูลและอาจมีประโยชน์ในบางภาษาที่ทับทิม แต่สำหรับภาษาเช่น C #, Java, C ++ ฉันสงสัยว่าการประชุม "7 บรรทัด" นี้ ให้ฉันเป็นตัวอย่างแอปพลิเคชั่นปัจจุบันของฉันมี 22 ช่องข้อความและฉันทำการตรวจสอบฝั่งเซิร์ฟเวอร์ เมธอดนี้เรียกว่า validateInput () และการตั้งค่าของฉันจะตรวจสอบความถูกต้องของฟิลด์ทั้งหมดในวิธีเดียวยกเว้นว่าฉันได้ตรวจสอบบางอย่างที่ซับซ้อนเช่น checkEmailFormat () ดังนั้นโดยทั่วไปโค้ดวิธี validateInput ของฉันคือ 108 บรรทัดที่มีการเรียกใช้การตรวจสอบที่ซับซ้อนเป็นครั้งคราว

ตอนนี้ลองคิดดูถ้าฉันเรียก 25 วิธีในการตรวจสอบแต่ละฟิลด์ หากนักพัฒนาใหม่เข้ามาเขาจะต้องเข้าและออกจากวิธีการหลักเพื่อข้ามไป 25 วิธีซึ่งอาจจะเรียกอีกสองสามวิธี เขาผูกพันที่จะหลงทางในโครงการใหญ่ ๆ

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

validateInput (ผู้ใช้ UserObj) {

// ยืนยันชื่อจริง ....... ......

// ตรวจสอบความถูกต้องของชื่อ ......

// ตรวจสอบอีเมล ..... // ซับซ้อนเกินกว่าที่จะตรวจสอบรูปแบบอีเมลปกติ checkEmailFormat expresion (); ....

และอื่น ๆ .. }

กฎไม่ดี ด้วยรหัสสำหรับการจัดการข้อยกเว้นการตั้งค่าฟิลด์ฐานข้อมูลการตรวจสอบวิธีส่วนใหญ่จะอยู่ภายใต้ข้อความสั่งเจ็ดรายการได้อย่างไร เราไม่ควรทำฟังก์ชั่นแลมบ์ดาแบบอินไลน์หรือไม่?

บรรทัดของโค้ดเป็นการนับความซับซ้อนตามอำเภอใจ ด้วยวิธีการขยายฉันสามารถสร้างรหัสเช่น

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

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

ขณะนี้ฉันกำลังดูวิธีการของโค้ด 550 บรรทัดโดยมีคำสั่ง if อื่น ๆ มากมายและดำเนินการต่อและส่งคืนทอปมัน มันอึ หากโปรแกรมเมอร์ถูกบังคับให้คิดเกี่ยวกับสิ่งที่เขาทำ ...