การตีความรหัสต้นฉบับของผู้อื่น [ปิด]

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

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

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

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

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

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

เคล็ดลับแรก: ใช้ IDE (หรือตัวแก้ไขที่ดีมาก :)) เพื่อดูข้อผิดพลาดทางไวยากรณ์วงเล็บผิดตำแหน่งและข้อผิดพลาดเล็กน้อยอื่น ๆ

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

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

เพิ่มความคิดเห็นให้กับตัวคุณเองเมื่อคุณค้นพบว่าฟังก์ชัน / วิธีการใดที่ทำอยู่

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

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

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

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

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

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

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

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

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

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

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

ฉันเกลียดที่จะพูดแบบนี้ แต่ไม่มีกระสุนเงินที่นี่

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

สำหรับโน้ตที่ใช้งานได้จริงการใช้ IDE อัจฉริยะคือขั้นตอนที่ 1

ขั้นตอนที่ 2 จะเรียกใช้doxygenหรือสิ่งที่คล้ายกันเพื่อหาลำดับชั้นของซอร์สโค้ด

ขั้นตอนที่ 3 คือการหาฟังก์ชั่นสมอหรือวัตถุสิ่งที่ประมวลผลบรรทัดคำสั่งหรือไฟล์ของคุณแล้วดำเนินการตรรกะ

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

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

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

ฉันถูกถามบ่อยเหมือนกันในห้องแล็บในโรงเรียน โดยปกติคำถามเริ่มต้นด้วย "ฉันจะแก้ไขข้อผิดพลาดของคอมไพเลอร์นี้ได้อย่างไร" ดังนั้นฉันจึงค่อนข้างดีที่จะสังเกตเห็นห้อยห้อยelseอัฒภาคที่ขาดหายไปและสิ่งที่คล้ายกัน (แมโครนั้นสนุกกับการดีบักเช่นกัน - #define CUBE(x) x * x * xเป็นความผิดพลาดที่เราทุกคนกำหนดไว้) ข้อได้เปรียบที่ฉันได้รับคือฉันได้ผ่านชั้นเรียนเดียวกันกับครูคนเดียวกันดังนั้นฉันจึงคุ้นเคยกับข้อกำหนดนี้แล้ว

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

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

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