ความเรียบง่ายปรับปรุงความสามารถในการอ่านได้เสมอหรือไม่

เมื่อเร็ว ๆ นี้ฉันกำลังพัฒนามาตรฐานการเข้ารหัสสำหรับ บริษัท ของเรา (เราเป็นทีมใหม่ที่แยกสาขาออกเป็นภาษาใหม่สำหรับ บริษัท )

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

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

อย่างไรก็ตามฉันได้ตั้งข้อสงสัยเกี่ยวกับการผลักดันนี้:

ความเรียบง่ายช่วยเพิ่มความสะดวกในการอ่านหรือไม่?

มีกรณีที่การเขียนรหัสที่เรียบง่ายลดการอ่านหรือไม่?

ควรชัดเจน แต่โดย "เรียบง่าย" ฉันไม่ได้หมายถึง "ง่ายต่อการเขียน" แต่สิ่งต่าง ๆ เกิดขึ้นน้อยกว่าต่อบรรทัด

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

ฉันจะใช้เป็นตัวอย่างรหัส Haskell ที่ฉันเขียนไปสักพักแล้ว ฉันถามคำถามเกี่ยวกับstackoverflowเกี่ยวกับการใช้ List monad เพื่อคำนวณตัวนับที่แต่ละหลักอาจมีฐานที่แตกต่างกัน วิธีแก้ปัญหาในที่สุดของฉัน (ไม่ทราบมาก Haskell) ดูเหมือนว่า:

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

หนึ่งในคำตอบช่วยลดสิ่งนี้เป็น:

count = mapM (enumFromTo 0)

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

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

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

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

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

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

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

เสมอ? - ไม่

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

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

ถ้าฉันไปเพื่อความเรียบง่ายฉันสามารถเขียนโค้ดแบบนี้:

10000000000000000000000000000000000000000000

แต่ถ้าฉันอ่านได้ฉันจะชอบสิ่งนี้:

1e43

ในทางกลับกัน1000สามารถอ่านได้และเรียบง่ายกว่า1e3เว้นแต่คุณจะทำงานกับตัวเลขในรูปแบบทางวิทยาศาสตร์ตลอดเวลา

นี่เป็นตัวอย่างที่เลวลงของรูปแบบทั่วไปที่มีอยู่มากมายที่คุณสามารถหาได้แทบทุกที่การสร้างบางสิ่งจากบล็อกที่เรียบง่ายอาจกลายเป็นสิ่งที่อ่านไม่ได้ / ไม่มีประสิทธิภาพ / ไม่ดีในหลาย ๆ วิธี ในทางกลับกันการใช้งานทั่วไปและการนำกลับมาใช้ใหม่ทำได้ยากขึ้น ("wtf is?! eพวกเขาหมายถึงการเขียน1343หรือไม่" มีคนพูดว่า) แต่สามารถช่วยได้มากในระยะยาว

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

ความคมชัดมาตรฐาน + + รหัสเรื่องการใช้งาน + ความคิดเห็นที่ดี + การออกแบบที่ดี สามารถปรับปรุงการอ่าน

ความเรียบง่ายไม่ได้อยู่ในมือของนักพัฒนาเสมอเพราะธรรมชาติของอัลกอริธึมและความซับซ้อนของโครงสร้างแอปพลิเคชันในทุกวันนี้

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

ความเรียบง่ายช่วยเพิ่มความสะดวกในการอ่านหรือไม่?

ไม่ฉันเคยเห็นหลายกรณีที่การทำสิ่งต่าง ๆ ที่ง่ายกว่าในหนึ่งบรรทัดนั้นซับซ้อนน้อยกว่าการมีหลายบรรทัด

มีข้อเสียระหว่างรหัสน้อยกับรหัสที่ง่ายกว่า

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

"ทำสิ่งต่าง ๆ ให้ง่ายที่สุดเท่าที่จะทำได้ แต่ไม่ง่ายกว่า" - การถอดความของ Albert Einstein บ่อยครั้ง

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

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

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

อีกตัวอย่างหนึ่ง: นิพจน์ทั่วไปมีจำนวนมากโดยทั่วไปจะมีเพียงหนึ่งบรรทัดและค่าที่เทียบเท่าโดยไม่มี regex นั้นมักอ่านได้ยากกว่ามาก / \ d {3} [-] \ d {3} - \ d {4} / เทียบเท่ากับการเรียกใช้ฟังก์ชันที่มีข้อคิดเห็นหลายอย่างเป็นอย่างน้อยและง่ายต่อการเข้าใจมากกว่าฟังก์ชั่นที่สอดคล้องกัน

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

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

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

ดังนั้นชื่อตัวแปรที่ยาวขึ้นอาจเลือก ...

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

if (some_boolean == true)ในทำนองเดียวกันผมอาจจะเขียน เมื่อเปรียบเทียบกับทางเลือกอื่นที่เทียบเท่าif (some_boolean)...

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

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

ซึ่งเป็นหลักฐานเพิ่มเติมของความเป็นส่วนตัวโดยรวมแน่นอน

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

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

10000000000000000000000000000000000000000000

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

1e43

คุณสามารถอธิบายข้อมูลโค้ด "ง่าย" ของ Aidanว่าทำสิ่งใดได้บ้าง มันมีรหัส 10 บรรทัด (ไม่นับความคิดเห็น) และอย่างน้อย 7 ช่วงตึก (ตามที่ฉันนับ) หากคุณติดตามความคิดเห็นคุณจะเห็นว่ามันทำอย่างน้อย 4 อย่าง!

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

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

count = mapM (enumFromTo 0)

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

ความเรียบง่ายช่วยเพิ่มความสะดวกในการอ่านหรือไม่?

ผมจะบอกว่าอาจจะมีนิด ๆ หน่อย ๆ ของการโต้เถียงอย่างไม่

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

ฉันต้องการคลาสที่มีฟังก์ชั่นสมาชิก 20 ฟังก์ชั่นที่ไม่ง่ายต่อการอ่านถึง 200 ที่เป็นเพราะ "ความสามารถในการอ่าน" นั้นไม่ใช่สิ่งที่สำคัญที่สุดสำหรับฉันในแง่ของการป้องกันข้อผิดพลาดของมนุษย์และปรับปรุงการบำรุงรักษาของรหัส เราสามารถเปลี่ยนได้คือ)

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

ความง่าย

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

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

เสียงกระเพื่อม

แต่ฉันมีความหลงใหลสั้น ๆ กับ LISP ประมาณกลางทศวรรษที่ 90 (ผู้มาที่หลัง) มันเปลี่ยนความคิดทั้งหมดของฉัน "ความเรียบง่าย"

LISP ไม่ใช่ภาษาที่อ่านได้มากที่สุด หวังว่าไม่มีใครคิดว่าการแยก CDRs และ CARs ในขณะที่เรียกใช้ฟังก์ชั่นแบบเรียกซ้ำด้วยการโหลดวงเล็บซ้อนกันในวงเล็บนั้นเป็น "ที่อ่านได้" มาก

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

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

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

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

minimalism

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

ความปลอดภัย

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

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

sword = sharpen(sword)

... ตรงไปตรงมาน้อยกว่าและแยกออกจากความคิดของมนุษย์น้อยกว่า:

sharpen(sword)

VS การอ่าน ความง่าย

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

ด้วยคำจำกัดความแบบ "เรียบง่าย" บางครั้ง "เรียบง่าย" อาจแข่งขันกับ "อ่าน" ได้บ้าง สิ่งนี้กำลังพิจารณาสิ่งต่าง ๆ เพิ่มเติมจากมุมมองการออกแบบอินเตอร์เฟส

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

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

Regex เป็นตัวอย่างของสิ่งที่ฉันพิจารณาว่า "ง่ายมาก" มัน "ง่ายเกินไปและอ่านไม่ได้" สำหรับรสนิยมส่วนตัวของฉัน มีการกระทำที่สมดุลสำหรับฉันระหว่างสุดขั้วเหล่านี้ แต่ regex มีคุณภาพเหมือน LISP ที่เรียบง่ายตามที่ฉันกำหนดไว้: ความเรียบง่ายสมมาตรสมมาตรความยืดหยุ่นอย่างไม่น่าเชื่อความน่าเชื่อถือ ฯลฯ ปัญหาสำหรับฉันกับ regex คือมันง่ายมาก กลายเป็นอ่านไม่ได้จนถึงจุดที่ฉันไม่คิดว่าฉันจะคล่องแคล่ว (สมองของฉันก็ไม่ทำงานอย่างนั้นและฉันอิจฉาคนที่สามารถเขียนรหัส regex ได้อย่างคล่องแคล่ว)

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

เสมอ? - ใช่

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

มุ่งเน้นไปที่พื้นที่ที่มีกลุ่มแนวคิดรวบยอดหนาแน่นและหาวิธี "สรุป" หรือ "สรุป" หรือ "นามธรรม" สร้างรหัสผ่านสองสามชุดเพื่อให้ง่ายและอ่านง่ายขึ้น

สิ่งที่เป็นนามธรรมที่ดีมีค่าเท่ากับน้ำหนักของทองคำ สิ่งที่เป็นนามธรรมทำให้สิ่งนี้ง่ายขึ้นและอ่านง่ายขึ้น

คำถามทำให้ฉันนึกถึงคำตอบนี้ใน Stack Overflow โดยเฉพาะข้อความนี้ (คุณภาพทดแทนด้วยความเรียบง่าย):

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

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

ฟังก์ชั่นการโทรหนึ่งครั้งต่อบรรทัดนั้นง่ายกว่าไหม? ลองตัวอย่าง!

=== One call per line ===
x = y.getThis()
a = x.getThat()
b = a.getSomethingElse()

=== Less "simple" version ===
b = y.getThis().getThat().getSomethingElse()

คุณคิดอย่างไร? การโทรหนึ่งครั้งต่อบรรทัดง่ายกว่าจริงหรือไม่