มีวิธีในการแยกแยะความเห็นข้อมูลจากรหัสความคิดเห็นออก?

36

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

// A concise description 
const a = Boolean(obj);
//b = false;

มีวิธีที่ดีในการแยกวิเคราะห์อย่างรวดเร็วว่าอันไหน

ฉันเล่นรอบโดยใช้ 3 /และ/** */สำหรับความคิดเห็นอธิบาย

ฉันยังใช้ปลั๊กอิน VSCode เพื่อเน้น//TODO:และ//FIXME:

javascript comments

— คนเก่ง
แหล่งที่มา

2

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

— Justin เวลา 2 Reinstate Monica

1

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

— Artemis Fowl

187

มีวิธีแก้ไขปัญหาที่ง่ายมากคือลบโค้ดที่ใส่ความเห็นออก

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

— โรเบิร์ตฮาร์วีย์
แหล่งที่มา

108

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

— marstato

38

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

— usr

76

@usr: เมื่อรหัสถูกลบไม่มีใครสังเกตเห็นมันเคยมีอยู่ - และจากประสบการณ์ของฉันใน 99% ของกรณีโลกแห่งความจริงทั้งหมดที่เป็นสิ่งที่ถูกต้อง ใน 1% อาจมีค่าบางอย่างในบรรทัดที่ล้าสมัยอย่างไรก็ตามหากรหัสที่ถูกใส่ความเห็นยังคงอยู่เป็นเวลาหลายสัปดาห์หรือหลายเดือน (หรือนานกว่า) โอกาสสูงนั้นจะไม่ได้รวบรวมอีกต่อไป บรรทัดรหัส อาร์กิวเมนต์ "ค่านิยมเพื่อการใช้ในอนาคต" มักถูกใช้เป็นข้ออ้างที่ไม่ถูกต้องโดยผู้ที่มีปัญหาทางอารมณ์ในการลอกสิ่งต่าง ๆ ออกจากรหัสฐานที่พวกเขาลงทุนกับสมองมาหลายชั่วโมง

— Doc Brown

21

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

— James Beninger

30

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

— Erik

45

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

# TODO: Replace with `foo = frobnicate(bar)` once <link.to/bug> is fixed
foo = [some complex workaround]

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

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

— l0b0
แหล่งที่มา

2

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

— Monty Harder

3

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

— supercat

20

อืมฉันอ่านคำถามนี้แตกต่างจากโรเบิร์ตเล็กน้อยซึ่งยืนยันว่าควรลบรหัสความเห็นออกอย่างถูกต้อง

อย่างไรก็ตามหากคุณกำลังมองหาการประชุมเพื่อทำเครื่องหมายรหัสสำหรับการลบในภายหลังรายการโปรดเก่าของฉันคือ:

//b = false; //TODO: remove

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

แยกอย่างรวดเร็วซึ่งเป็นสิ่งที่?

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

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

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

— candied_orange
แหล่งที่มา

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

— TheHansinator

3

@TheHansinator ที่ฟังดูดี แต่ประสบการณ์ของฉันกับโทรศัพท์มือถือของฉันโดยอัตโนมัติความสัมพันธ์ที่ถูกต้องกับศัพท์แสง coder ของฉันทำให้ฉันระมัดระวัง

— candied_orange

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

— TheHansinator

3

การแยกวิเคราะห์ wrt: double buffer (flip on)-> ต้นแบบ C หรือภาษาอังกฤษตัวย่อ? ไม่สามารถบอกได้โดยไม่มีบริบทไม่ใช่โครงสร้างที่ถูกต้องทั้งในภาษาใดภาษาหนึ่ง ผลบวกและเชิงลบที่ผิดพลาดบางอย่างนั้นหลีกเลี่ยงไม่ได้เมื่อความคิดเห็นโดยธรรมชาติของพวกเขาไม่ได้ จำกัด รูปแบบเนื้อหาของพวกเขาในทิศทางใดทิศทางหนึ่ง

— Leushenko

8

ฉันใช้คำสั่ง preprocessor เพื่อลบรหัสไม่ใช่ความคิดเห็นเลย:

//comment
active_code();
#if FALSE
inactive_code();
#endif

สิ่งนี้ทำให้การค้นหาง่ายมากและเครื่องมือเน้นข้อความของฉันถือว่าเป็นความคิดเห็น ฉันยังสามารถยุบมันเป็นบรรทัดเดียว:#if FALSE(...)

คุณสามารถขยายความคิดนั้นให้มีหลายตัวเลือก:

#if OPTION == 0
code_for_option_0();
#elif OPTION == 1
code_for_option_1();
#else
code_for_all_other_options();
#endif

และรวบรวมเวลาตรวจสอบข้อผิดพลาด:

#if FOO >= 5
#error FOO should be less than 5!
#endif

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

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

— AaronD
แหล่งที่มา

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

— Tvde1

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

— AaronD

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

— AaronD

3

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

— VLAZ

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

— AaronD

4

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

(พื้นฐานของฉันคือ C # แต่สามารถใช้ได้กับภาษา C-syntax ใด ๆ เช่น java)

// An explanatory comment has a space between the comment marker and the content.

// The following lines are commented out code so do not have the space (except where indented).
//var a = something();
//if(a==2) {
//   doSomethingElse();
//}

— IanF1
แหล่งที่มา

2

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

— cmaster

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

— IanF1

2

ฉันกำลังตีความคำถามที่แตกต่างกันยังคงคิดว่าคุณต้องการค้นหารหัสออกความเห็น

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

\s*\/\/[\s\S]*;

สำหรับโค้ดที่แสดงความคิดเห็นหลายบรรทัดอาจเป็นไปได้

\/\*[^\;]*;[^\;]*\*\/

หมายเหตุ Visual Studio เป็นบิตที่แปลกประหลาดเกี่ยวกับตัวแบ่งบรรทัดในนิพจน์ทั่วไปโดยไม่นับเป็นช่องว่างคุณต้องระบุ \ n อย่างชัดเจน

— Martin Maat
แหล่งที่มา

2

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

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

— gnasher729
แหล่งที่มา

1

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

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

— ทำจากแป้งที่ยังไม่ได้ร่อน
แหล่งที่มา

-3

ง่ายอย่างน้อยสำหรับฉัน - และใน C / C ++ ความคิดเห็นที่อยู่ใน / * * / เป็นข้อมูล รหัสทดสอบที่ถูกลบชั่วคราวจะใส่เครื่องหมายด้วยชั้นนำ //

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

— jamesqf
แหล่งที่มา

นอกจากนี้ยังมี#ifdef __DEBUG ... #endifหรือข้อกำหนดที่กำหนดเองใด ๆ ที่คุณต้องการใช้ __DEBUGเป็นเรื่องที่ดีเพราะคุณมักจะต้องเปลี่ยนการกำหนดค่าโครงการเพื่อให้ได้เท่านั้น แต่ IDE ส่วนใหญ่ให้คุณกำหนดค่าของคุณเองเช่นกันซึ่งสามารถให้อะไรคุณได้ในจุดนั้น

— AaronD

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

— คอมเม้นต์โค้ด

1

โอ๊ะอย่าทำอย่างนั้น การแสดงความคิดเห็นรหัส "เพื่อทดสอบบางอย่าง" จะทำงานได้อย่างสมบูรณ์ 99 จาก 100 ครั้ง ... และในกรณีเดียวคุณจะลืมลบ (ถ้าไม่ต้องการอีกต่อไป) หรือ - ยิ่งแย่กว่า - ลืมที่จะไม่แสดงความคิดเห็น ( ถ้าจำเป็น) และสิ่งต่าง ๆ อาจจะน่าเกลียด

— CharonX

@leftaroundabout: ไม่ฉันหมายถึงสิ่งต่าง ๆ เช่นคำสั่ง printf ที่ใส่เพื่อตรวจสอบค่า

— jamesqf

@jamesqf คุณไม่ควรต้องการอะไรแบบนั้นนั่นคือสิ่งที่มีการดีบั๊ก แต่แม้ว่าคุณจะใช้printf/ coutหรือคล้ายกันในการรับรหัสที่ถูกต้องใหม่ (ซึ่งฉันยอมรับว่าฉันได้ทำเองมาแล้วในอดีต) มันไม่ได้มีประสิทธิภาพมากนักที่จะปล่อยพวกเขาไว้ที่นั่น หากใครบางคนต้องการเปลี่ยนแปลงและรู้ว่าตัวแปรใดที่พวกเขาต้องการข้อมูลเกี่ยวกับมันเป็นเรื่องง่ายและรวดเร็วในการเขียนprintfใหม่ในขณะที่ถ้า dev นั้นไม่รู้ว่าจำเป็นต้องใช้อะไรและยกเลิกprintfการคอมเม้นท์ข้อความเหล่านั้นทั้งหมดเทอร์มินัลน่าจะไม่ช่วยพวกเขาเช่นกัน

— leftaroundabout