รหัสดีบั๊กควรอยู่ในตำแหน่งตลอดเวลาหรือเพิ่มเฉพาะเมื่อทำการดีบั๊กและลบออกเมื่อพบข้อบกพร่องหรือไม่

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

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

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

รหัสที่เพิ่มเข้ามาโดยเฉพาะสำหรับการแก้ไขข้อบกพร่องควรถูกลบออกจากซอฟต์แวร์การผลิต

ไม่ว่าจะเป็นการลบแบบสมบูรณ์หรือถูกใส่ไว้ในส่วนการรวบรวมตามเงื่อนไข (เช่นใน C / C ++ / C #) ขึ้นอยู่กับคุณและมาตรฐานการเข้ารหัสของคุณ

มีสาเหตุหลายประการ:

1. อาจมีผลกระทบด้านความปลอดภัยหากมีการเรียกใช้รหัสนี้หรือใครบางคนสามารถเข้าถึงผลลัพธ์ได้
2. อาจทำให้แอปพลิเคชันช้าลง
3. มันอาจสร้างความสับสนให้กับนักพัฒนาคนอื่น ๆ ที่มองรหัส

ChrisFและAlaricทั้งสองมีคะแนนที่ถูกต้อง; +1 สำหรับพวกเขา ฉันสามารถระบุรหัสการดีบักได้อย่างน้อย 5 ชนิดที่ฉันใช้

1. การใช้บันทึกเพื่อถ่ายโอนข้อมูลสถานะระบบ ณ เวลาใดเวลาหนึ่ง

   void function(...)
   {
       ...dump everything i know about.
   }
   

2. การใช้บันทึกสำหรับจุดตรวจสอบการดำเนินการ

   void function(...)
   {
       ...got here 1
       ...got here 2
   }
   

3. รหัสที่จริงบังคับให้เงื่อนไขบางอย่างเป็นจริง แต่แบ่งพฤติกรรมปกติ ตัวอย่าง:

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

4. การบันทึกการตรวจสอบ - ฉันจะจัดประเภทนี้เป็นการบันทึกข้อมูล verbose ที่สามารถใช้ในการตรวจสอบความถูกต้องของซอฟต์แวร์ที่ไม่ควรรวมอยู่ในการผลิตเช่นการตรวจสอบขั้นตอนแต่ละขั้นตอนของอัลกอริทึม

5. การดำเนินการเข้าสู่ระบบ - หมายถึงการโพสต์ของ Alaric นั่นคือสิ่งที่ฉันหมายถึงโดย "การบันทึกการดำเนินงาน"

1, 2 และ 3 ควรถอดออกโดยสมบูรณ์ บางอย่างเช่น 4 ฉันอาจรวบรวมจากรหัสเงื่อนไข สำหรับ 5, Alaricมีจุดที่ดีเกี่ยวกับความสามารถในการปิดล็อกแบบไดนามิก นั่นอาจกล่าวถึงประเด็นของ ChrisFในกระสุนนัดที่สองของเขาสำหรับกรณีส่วนใหญ่

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

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

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

รหัสที่คุณเพิ่มเพียงเพื่อติดตามข้อผิดพลาดที่เฉพาะเจาะจงมักจะถูกลบออกหลังจากที่คุณพบข้อผิดพลาด

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

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

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

ประสบการณ์การแก้ไขข้อบกพร่องเดียวที่ฉันพบว่าแย่กว่านั้นคือ GDB บรรทัดคำสั่ง

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

เมื่อถึงเวลาที่ฉันทำงานใน Visual Studio 7 แต่ก็ชัดเจนว่าการดีบักอาจใช้งานได้จริงและมีประสิทธิภาพ หากคุณสามารถทำการดีบักใน Visual Studio (รวมรุ่นด่วน) การดีบักเป็นเรื่องง่าย ไม่ต้องสงสัยเลยว่าถ้าคุณสามารถหาส่วนหน้า GUI / IDE ที่ถูกต้อง GDB นั้นก็ง่ายและมีประสิทธิภาพเช่นกัน แต่ฉันยังไม่ได้ทำการค้นหา

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

tool = cmake สำคัญอย่างไม่คาดคิดเครื่องมือสร้างที่ช่วยให้ฉันสามารถสลับระหว่างการสร้างสำหรับ GCC และ VC ++ ได้อย่างง่ายดายเหนือสิ่งอื่นใด ดังนั้นฉันสามารถทำการทดสอบหน่วยและครอบคลุม gcov โดยใช้ GCC แต่เปลี่ยนเป็น VC ++ ได้อย่างง่ายดายเพื่อใช้ดีบักเกอร์

My take on it: Debug code ที่ใช้ฆ่า bug ภายในโค้ดที่เป็นปัญหาโดยทั่วไปแล้วฉันจะลบออกทั้งหมด รหัสการแก้ปัญหาที่ใช้ในการฆ่าแมลงที่เกิดจากแรงภายนอกฉันมักจะแสดงความคิดเห็น

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

ใช้TDDดังนั้นโค้ดทดสอบของคุณจะมีสถานที่ที่สม่ำเสมอ