“ ง่ายต่อการให้เหตุผล” - นั่นหมายความว่าอย่างไร [ปิด]

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

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

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

ในใจของฉันวลี "เหตุผลง่าย ๆ เกี่ยวกับ" หมายถึงรหัสที่ง่ายต่อการ "ดำเนินการในหัวของคุณ"

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

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

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

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

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

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

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

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

ในทางตรงกันข้าม OO มักจะยากที่จะให้เหตุผลมากกว่าเพราะ "เอาท์พุท" ที่ผลิตขึ้นอยู่กับสถานะภายในของทุกวัตถุที่เกี่ยวข้อง วิธีการทั่วไปที่ปรากฏเป็นผลข้างเคียงที่ไม่คาดคิด: เมื่อเปลี่ยนส่วนหนึ่งของรหัสส่วนแบ่งที่ไม่เกี่ยวข้องปรากฏ

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

อย่างไรก็ตามมีอีกหลายสิ่งที่ยากกว่าที่จะให้เหตุผลและฉันเห็นด้วยกับ @Kilian ว่าการเห็นพ้องด้วยเป็นตัวอย่างที่ดี ระบบกระจายเกินไป

หลีกเลี่ยงการอภิปรายที่กว้างขึ้นและตอบคำถามเฉพาะ:

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

ฉันแนะนำคุณให้รู้จักกับ"The Story of Mel, Real Programmer"ชิ้นส่วนของคติชนโปรแกรมเมอร์ที่มีอายุถึงปี 1983 และนับได้ว่าเป็น 'ตำนาน' สำหรับอาชีพของเรา

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

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

นี่คือตัวอย่างของรหัสที่ 'ยากที่จะให้เหตุผลเกี่ยวกับ'

แน่นอนเมลจะไม่เห็นด้วย ...

ฉันสามารถยกตัวอย่างและเป็นเรื่องธรรมดามาก

พิจารณารหัส C # ต่อไปนี้

// items is List<Item>
var names = new List<string>();
for (var i = 0; i < items.Count; i++)
{
    var item = items[i];
    var mangled = MyMangleFunction(item.Name);
    if (mangled.StartsWith("foo"))
    {
        names.Add(mangled);
    }
}

พิจารณาทางเลือกนี้

// items is List<Item>
var names = items
    .Select(item => MyMangleFunction(item.Name))
    .Where(s => s.StartsWith("foo"))
    .ToList();

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

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

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

วลีที่เกี่ยวข้องคือ (ฉันแปลความหมาย)

รหัสไม่เพียงพอที่จะมี " ไม่มีข้อบกพร่องที่เห็นได้ชัด ": แต่ควรมี " เห็นได้ชัดว่าไม่มีข้อบกพร่อง "

ตัวอย่างของความ "ง่ายที่จะให้เหตุผลเกี่ยวกับ" อาจจะRAII

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

ปมของการเขียนโปรแกรมคือการวิเคราะห์กรณี Alan Perlis กล่าวถึงเรื่องนี้ใน Epigram # 32: โปรแกรมเมอร์ไม่ควรวัดด้วยความเฉลียวฉลาดและตรรกะของพวกเขา แต่ด้วยความสมบูรณ์ของการวิเคราะห์กรณีของพวกเขา

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

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

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

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

แน่ใจ ใช้งานพร้อมกัน:

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

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

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

ให้เรา จำกัด ภารกิจไว้ที่การใช้เหตุผลอย่างเป็นทางการ เพราะการใช้เหตุผลเชิงอารมณ์ขันหรือการประดิษฐ์หรือบทกวีมีกฎหมายที่แตกต่างกัน

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

โครงสร้าง "เหตุผลง่าย ๆ เกี่ยวกับ" ควรได้รับคะแนนที่ดีดังต่อไปนี้:

• คำศัพท์ด้านในมีชื่อที่สมเหตุสมผลแตกต่างและกำหนดได้ง่าย หากองค์ประกอบมีลำดับชั้นความแตกต่างระหว่างชื่อพาเรนต์และชื่อลูกควรแตกต่างจากความแตกต่างระหว่างชื่อพี่น้อง
• จำนวนชนิดขององค์ประกอบโครงสร้างอยู่ในระดับต่ำ
• องค์ประกอบโครงสร้างชนิดใช้แล้วเป็นสิ่งง่าย ๆ ที่เราคุ้นเคย
• องค์ประกอบที่เข้าใจได้ยาก (การเรียกซ้ำขั้นตอนเมตาเรขาคณิต 4 มิติ + ... ) ถูกแยกออก - ไม่รวมเข้าด้วยกันโดยตรง (ตัวอย่างเช่นหากคุณพยายามคิดว่าการเปลี่ยนกฎแบบวนซ้ำสำหรับ 1,2,3,4 ..n. มิติลูกบาศก์มันจะซับซ้อนมาก แต่ถ้าคุณจะเปลี่ยนกฎเหล่านี้เป็นสูตรบางสูตร ทั้งนี้ขึ้นอยู่กับ n คุณจะมีสูตรแยกต่างหากสำหรับทุก n-cube และกฎการเรียกซ้ำสำหรับสูตรดังกล่าวแยกจากกันและโครงสร้างทั้งสองแยกจากกันสามารถนึกถึงได้ง่าย)
• ประเภทขององค์ประกอบโครงสร้างแตกต่างกันอย่างเห็นได้ชัด (ตัวอย่างเช่นไม่ใช้อาร์เรย์ผสมเริ่มต้นจาก 0 และจาก 1)

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

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

สำหรับตัวอย่างของระบบการให้เหตุผลใน pi-แคลคูลัสตำแหน่งหน่วยความจำที่ไม่แน่นอนแต่ละตำแหน่งในภาษาที่จำเป็นจะต้องแสดงเป็นกระบวนการคู่ขนานที่แยกจากกันในขณะที่ลำดับของการดำเนินงานการทำงานเป็นกระบวนการเดียว สี่สิบปีต่อจากทฤษฎีบท LFC เรากำลังทำงานกับ GB of RAM ดังนั้นการมีหลายร้อยโพรเซสจึงเป็นปัญหาน้อยลง - ฉันใช้ pi-แคลคูลัสเพื่อกำจัดการหยุดชะงักที่อาจเกิดขึ้นจาก C ++ สองสามร้อยบรรทัด กระบวนการที่ผู้ดำเนินการใช้ทำให้พื้นที่ของรัฐหมดไปประมาณ 3GB และแก้ไขข้อผิดพลาดเป็นระยะ สิ่งนี้คงเป็นไปไม่ได้ในยุค 70 หรือต้องการซูเปอร์คอมพิวเตอร์ในช่วงต้นทศวรรษ 1990 ในขณะที่พื้นที่ของโปรแกรมภาษาที่ใช้งานขนาดเท่ากันนั้นมีขนาดเล็กพอที่จะให้เหตุผลในตอนนั้น

จากคำตอบอื่น ๆ วลีนี้กลายเป็นวลีที่ฉวัดเฉวียนแม้ว่าความยากลำบากมากมายที่ทำให้มันยากที่จะให้เหตุผลเกี่ยวกับภาษาที่จำเป็นถูกกัดกร่อนโดยกฎของมัวร์

เหตุผลที่เข้าใจง่ายคือคำศัพท์เฉพาะทางวัฒนธรรมซึ่งเป็นเหตุผลว่าทำไมจึงยากที่จะหาตัวอย่างที่เป็นรูปธรรม มันเป็นคำที่ยึดกับคนที่จะทำเหตุผล

"ง่ายต่อการให้เหตุผลเกี่ยวกับ" เป็นจริงวลีที่อธิบายด้วยตนเองมาก หากมีใครดูรหัสและต้องการให้เหตุผลว่ามันทำอะไรมันง่าย =)

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

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

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

สำหรับเหตุผลง่ายอีกครั้งคำที่มีวัฒนธรรมสูง คุณต้องพิจารณา:

• ผู้ใช้มีทักษะอะไร ประสบการณ์เท่าไหร่
• คำถามประเภทใดที่ผู้ใช้อาจมีเกี่ยวกับรหัส
• ผู้ให้เหตุผลจำเป็นต้องแน่ใจได้อย่างไร?

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

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

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

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