การใช้หลักการของ Clean Code กับภาษาที่ใช้งานได้


16

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

[W] e ต้องการให้สามารถอ่านโปรแกรมราวกับว่ามันเป็นชุดของย่อหน้า TO แต่ละอันจะอธิบายถึงระดับปัจจุบันของสิ่งที่เป็นนามธรรมและการอ้างอิงที่ตามมาถึงย่อหน้าในระดับถัดไป

( ทำความสะอาดรหัสหน้า 37: "TO วรรค" เป็นย่อหน้าที่เริ่มต้นด้วยประโยคที่เปล่งออกมาใน infinitive "ในการทำ X เราทำตามขั้นตอน Y และ Z" "เพื่อทำ Y เรา ... " ฯลฯ ) ตัวอย่างเช่น:

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

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

นำตัวอย่างออกจากไลบรารีมาตรฐาน Haskell :

maximumBy               :: (a -> a -> Ordering) -> [a] -> a
maximumBy _ []          =  error "List.maximumBy: empty list"
maximumBy cmp xs        =  foldl1 maxBy xs
                        where
                           maxBy x y = case cmp x y of
                                       GT -> x
                                       _  -> y

นั่นเป็นเรื่องที่ไกลที่สุดเท่าที่คุณจะได้รับจากคำแนะนำของมาร์ติน แต่มันก็สั้นกระชับ Haskell แตกต่างจากตัวอย่าง Java ในหนังสือของเขาฉันไม่สามารถจินตนาการถึงวิธีการ refactor ที่ในสิ่งที่มีจังหวะที่เขาถาม ฉันสงสัยว่า Haskell เขียนถึงมาตรฐานของClean Codeจะหลุดออกมาอย่างยืดเยื้อและไม่เป็นธรรมชาติ

ฉันผิดหรือไม่ที่จะต้องพิจารณา (อย่างน้อยบางส่วน) ทำความสะอาดโค้ดที่ขัดแย้งกับแนวทางปฏิบัติที่ดีที่สุดในการตั้งโปรแกรมการทำงาน มีวิธีที่เหมาะสมที่จะตีความสิ่งที่เขาพูดในกระบวนทัศน์ที่แตกต่างออกไปหรือไม่?


1
โปรแกรมเมอร์ที่ใช้งานได้มักจะเขียนโค๊ด terse มากเกินไปซึ่งเป็นความจริง ฉันจะไม่พิจารณาจากระยะไกลว่าวิธีปฏิบัติที่ดีที่สุดแม้ว่าในสภาพแวดล้อมนั้น
Telastyn

ยกโทษให้ความเขลา แต่เป็นสิ่งที่ต้องวรรค?
Shashank Gupta

4
ดังที่ถูกกล่าวถึงในคำถามอื่นเมื่อไม่นานมานี้ Dijkstra เขียนเกี่ยวกับความโง่เขลาของ "การเขียนโปรแกรมภาษาธรรมชาติ"และฉันมักจะเห็นด้วยกับเขาว่ารหัสที่อ่านเช่นร้อยแก้วเป็นความฝันที่ไพเราะ ฉันคิดว่านี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งใน Haskell ซึ่งบริสุทธิ์แสดงถึงความเท่าเทียมระหว่างสัญลักษณ์แทนค่าของลำดับขั้นเพื่อสร้างเอฟเฟกต์ ฉันคิดว่าสิ่งสำคัญคือรหัสที่ยกมาเป็นสำนวน เช่นxsเป็นชื่อที่ไม่ดี แต่เป็นเรื่องทั่วไปในภาษาที่ใช้งานได้เช่นเดียวiกับตัวแปรลูป
Doval

@ShashankGupta ฉันแก้ไขคำถามด้วยลิงก์ไปยังหน้าเฉพาะในหนังสือรวมทั้งความเข้าใจของฉันเองเกี่ยวกับสิ่งที่ลุงบ๊อบเขียน

@ShashankGupta เขายกตัวอย่างบางส่วน แต่ความคิดก็คือมันควรจะอ่านเหมือนร้อยแก้ว "เพื่อค้นหารายการสูงสุดคุณตรวจสอบทุกองค์ประกอบ ... "
Patrick Collins

คำตอบ:


11

รหัสสะอาดเป็นครั้งแรกและสำคัญที่สุดคู่มือสไตล์ Strunk and Whiteใช้ไม่ได้เมื่อคุณเขียนใน Klingon แนวคิดคือคุณต้องการให้ชัดเจนกับโปรแกรมเมอร์ที่จะอ่านรหัสของคุณ คุณต้องการมีรหัสที่ทำให้เป็นโมดูลและปรับโครงสร้างได้ง่าย มีวิธีการทำเช่นนี้ใน Haskell เช่นเดียวกับที่มีวิธีการทำเช่นนี้ในภาษาอื่น ๆ แต่รายละเอียดที่แม่นยำจะแตกต่างกันไป

ที่ถูกกล่าวว่ามีแนวทางสไตล์จำนวนมากสำหรับ Haskell Stack Overflow มีคำแนะนำที่ครอบคลุมพอสมควรเช่นกัน การเข้ารหัสเชิงตรรกะที่ตรงไปตรงมาและสั้น ๆ ดูเหมือนจะค่อนข้างคงที่ ฟังก์ชั่นการทำงานทั่วไปนั้นเน้นไปที่มันนำไปสู่การสร้างแบบแยกส่วน รหัส DRY นั้นเน้นเช่นเดียวกับ Clean Code

ในท้ายที่สุดแนวทางการเข้ารหัสของ Clean Code และ Haskell มุ่งมั่นในสิ่งเดียวกัน แต่จบลงด้วยการใช้เส้นทางของตนเองเพื่อไปที่นั่น


1
ฉันรู้สึกว่าคำตอบนี้มอบส่วนลดหลักการที่Clean Codeสอนซึ่งสามารถนำไปใช้ได้กับหลาย ๆ ภาษาและเป็นประเด็นหลักสำหรับคำถามที่ถาม ฉันเห็นได้ว่าทำไมคนถึงคิดว่าClean Codeเป็นคู่มือสไตล์และฉันคิดว่ามันเป็นความจริงบางส่วน แต่ไม่จริงพอที่จะยกเลิกทั้งเล่มเป็นเล่มเดียว
อัลลัน

ฉันไม่คิดว่าหนังสือ Clean Code ของ Martin เป็นคู่มือสไตล์ ฉันรู้สึกว่าคำสอนของหนังสือเล่มนี้พอดีกับบางอย่างระหว่างไกด์นำเที่ยวและลวดลายการออกแบบ
Michael R

15

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

แสดงในรูปแบบ "ถึงย่อหน้า" ของ Bob Martin ฉันอ่านตัวอย่างของคุณเป็น:

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

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

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.