การเขียนโค้ดที่ตายแล้วมีประโยชน์หรือไม่?

คุณคิดว่าการเขียนโค้ดตายมีประโยชน์หรือไม่?

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

ตัวอย่าง:-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

จริงป้ะ?

ฉันมักจะไม่เขียนโค้ดที่ตายแล้วแทนที่จะลบตรรกะที่สอง

IMO มันแย่กว่าไร้จุดหมาย

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

และถ้าแน่นอนมันเป็นความยุ่งเหยิงที่ทำให้โค้ดอ่านยากขึ้น

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

แก้ไข:

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

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

ในท้ายที่สุดคุณจะต้องลงเอยในรูปแบบของการบำรุงรักษาอย่างแน่นอน

ดังนั้นรหัสที่ดีที่สุดคือรหัสที่ถูกลบเนื่องจากไม่สามารถสร้างผลลัพธ์ที่ผิดหรือเบี่ยงเบนความสนใจของผู้ดูแลได้ :)

ไม่นั่นเป็นสิ่งที่ไม่ดีเพราะมันจะตัดรหัสของคุณและลดการบำรุงรักษา

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

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

ฉันสับสนโดยสุจริตในสิ่งที่คุณทำ

ตามลำดับความสำคัญจากมากไปน้อย:

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

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

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

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

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

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

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

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

หากคุณลบเฉพาะครั้งแรก /บรรทัดในบรรทัดความคิดเห็นแรกมันจะกลายเป็น:

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

ด้วยวิธีนี้คุณสามารถสลับไปมาระหว่างทางเลือกอื่นเพียงแค่เพิ่มหรือลบออก /ในรหัส

นี่อาจดูแปลก ๆ ในตอนแรก แต่เมื่อคุณคุ้นเคยกับมันคุณจะจำได้ง่ายว่าเป็นรูปแบบบางอย่าง

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

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

ฉันจะไม่ใช้วิธีนี้ แต่ใช้งานได้

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

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

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

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

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

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

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

ไม่ว่าในกรณีใดคุณจะจบลงโดยไม่มีรหัสตาย

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

NO

โปรแกรมเมอร์บางคนใช้รูปแบบนี้เป็นทางเลือกในการแสดงความคิดเห็นและดูดี

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

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

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

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

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

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

อาจมีเหตุผลในการเก็บรหัสความคิดเห็น (หรือใน C หรือ C ++, #ifdefรหัส ed out) แต่สิ่งนี้ควรมาพร้อมกับความคิดเห็นว่าทำไมมันถึงยังอยู่ที่นั่นและมีจุดประสงค์อะไร

โปรดทราบว่าใน Java ต่อไปนี้จะไม่ได้รวบรวมเนื่องจากรหัสที่ไม่สามารถเข้าถึงได้:

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

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

หากคอมไพเลอร์ของคุณพบคลาสข้อผิดพลาดให้คอมไพเลอร์พบมัน IMHO สิ่งที่ใครบางคนกำลังทำโดยการเขียนรหัสตายในลักษณะที่คุณอธิบายกำลังพยายามหลีกเลี่ยงข้อผิดพลาดของคอมไพเลอร์ซึ่งทำให้เกิดปัญหาใด ๆ ที่อาจทำให้เกิดการใช้งานจริง

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

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

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

ดูอีกว่ามันเป็นโปรแกรมเมอร์มืออาชีพส่วนใหญ่ยอมรับว่าขนาดของรหัสเป็นศัตรู ลองดูที่โพสต์บล็อกเหล่านี้: รหัสที่ดีที่สุดคือไม่มีรหัสโดย Jeff Atwood ศัตรูที่เลวร้ายที่สุดของ Codeโดย Steve Yegge คุณสามารถค้นหาได้มากขึ้น

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

สถานที่เดียวที่ฉันเห็นว่าสิ่งนี้มีประโยชน์คือในกรณีที่คุณต้องการปิดการใช้งานบางอย่างอย่างรวดเร็วและทดสอบ / แบ็กฟิล (บอกว่าโปรแกรมทำตามขั้นตอน A, B, C - ทั้งหมดใช้เวลานาน) ในระหว่างการทดแทน เวลาจะเร่งความเร็วถ้าคุณรู้ว่าไม่จำเป็น)
แต่ความจริงก็คือว่าในทุกกรณีนี้เป็นแฮ็คมาก และหากคุณเห็นการใช้งานระยะยาวสำหรับโค้ดทดแทนของคุณคุณควรเขียนโค้ดของคุณในลักษณะที่ใช้ config เพื่อเลือกตัวเลือกแทนที่จะใช้แฮ็กดังกล่าว
กฎอย่างรวดเร็วของฉันคือไม่เคยตรวจสอบรหัสประเภทนี้ หากคุณต้องการการควบคุมการเช็คอิน / เวอร์ชั่นหมายความว่าคุณจะสามารถกลับมาที่นี่อีกครั้งในไม่ช้าและนั่นก็เป็นสิ่งที่ไม่ดีเสมอในแง่ของการเปลี่ยนแปลงข้อกำหนด

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

เป็นสิ่งสำคัญอย่างยิ่งที่ข้อความแสดงข้อผิดพลาดระบุว่า "Panic: เราไม่ควรจะอยู่ที่นี่ที่บรรทัด% d ในไฟล์% s" ...