คำถามติดแท็ก comments

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

42 version-control  bug  comments  change 

มันเป็นการดีหรือไม่ที่จะใส่หมายเลขบั๊กในไฟล์ลงในความคิดเห็นส่วนหัว? ความคิดเห็นจะมีลักษณะเช่นนี้: MODIFIED (MM/DD/YY) abc 01/21/14 - Bug 17452317 - npe in drill across in dashboard edit mode cde 01/17/14 - Bug 2314558 - some other error description ดูเหมือนว่ามีประโยชน์ แต่ก็ถือว่าเป็นการปฏิบัติที่ไม่ดี?

40 version-control  development-process  source-code  comments 

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

38 comments  myth 

ตลอดหลักสูตรการเขียนโปรแกรมคุณจะพบกับความคิดเห็นบางส่วนที่อธิบายรหัสและความคิดเห็นบางส่วนที่นำรหัสออก: // A concise description const a = Boolean(obj); //b = false; มีวิธีที่ดีในการแยกวิเคราะห์อย่างรวดเร็วว่าอันไหน ฉันเล่นรอบโดยใช้ 3 /และ/** */สำหรับความคิดเห็นอธิบาย ฉันยังใช้ปลั๊กอิน VSCode เพื่อเน้น//TODO:และ//FIXME:

36 javascript  comments 

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

34 comments 

ความคิดเห็นได้รับการปฏิบัติโดยทั่วไปในภาษาการเขียนโปรแกรมและมาร์กอัปอย่างไร ฉันกำลังเขียนโปรแกรมแยกวิเคราะห์สำหรับภาษามาร์กอัปที่กำหนดเองบางอย่างและต้องการทำตามหลักการของความประหลาดใจน้อยที่สุดดังนั้นฉันจึงพยายามกำหนดรูปแบบทั่วไป ตัวอย่างเช่นความคิดเห็นที่ฝังอยู่ภายในโทเค็น 'รบกวน' กับโทเค็นหรือไม่? โดยทั่วไปแล้วเป็นสิ่งที่ชอบ: Sys/* comment */tem.out.println() ถูกต้อง? นอกจากนี้หากภาษามีความอ่อนไหวต่อบรรทัดใหม่และความคิดเห็นที่ครอบคลุมบรรทัดใหม่ควรพิจารณาบรรทัดใหม่หรือไม่? stuff stuff /* this is comment this is still comment */more stuff ถือว่าเป็น stuff stuff more stuff หรือ stuff stuff more stuff ? ฉันรู้ว่ามีบางภาษาที่เฉพาะเจาะจงทำหรือฉันกำลังมองหาความคิดเห็น แต่กำลังมองหาหรือไม่: มีฉันทามติทั่วไปสิ่งที่คาดหวังโดยทั่วไปโดยเครื่องหมายขึ้นเกี่ยวกับโทเค็นและบรรทัดใหม่หรือไม่? บริบทเฉพาะของฉันคือมาร์กอัปคล้ายวิกิ

31 parsing  comments 

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

27 language-agnostic  comments 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ฉันเห็นสิ่งนี้ถามใน SO Tavernดังนั้นฉันจึงโพสต์คำถามที่นี่ ฉันคิดว่ามันเป็นคำถามที่น่าสนใจ (แน่นอนว่ามันไม่ได้อยู่ในนั้น แต่ฉันคิดว่ามันโอเคที่นี่) คุณเพิ่มจุด (หรือตามที่ OP เขียนว่า "full stop") ในความคิดเห็นเกี่ยวกับโค้ดของคุณหรือไม่ เพื่อให้มันเกี่ยวข้องทำไม ?

27 source-code  comments  coding-style  grammar 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 8 ปีที่ผ่านมา ฉันต้องการคำแนะนำและประสบการณ์ในการเขียนความคิดเห็นจากคุณ คุณจะเขียนพวกเขาในวิธีที่ง่ายที่สุดและให้ข้อมูลได้อย่างไร คุณมีนิสัยอย่างไรเมื่อแสดงความคิดเห็นบางส่วนของรหัส บางทีคำแนะนำที่แปลกใหม่? ฉันหวังว่าคำถามนี้จะรวบรวมคำแนะนำและคำแนะนำที่น่าสนใจที่สุดสิ่งที่มีประโยชน์ที่ทุกคนสามารถเรียนรู้ได้ ตกลงฉันจะเริ่ม โดยปกติแล้วฉันไม่ได้ใช้/* */ความคิดเห็นแม้ว่าฉันจะต้องแสดงความคิดเห็นหลายบรรทัด ข้อดี : รหัสจะดูดีกว่าเมื่อคุณผสมไวยากรณ์ดังกล่าวกับความคิดเห็นแบบบรรทัดเดียว IDEs ส่วนใหญ่มีความสามารถในการแสดงความคิดเห็นข้อความที่เลือกและพวกเขามักจะทำมันด้วยไวยากรณ์บรรทัดเดียว ข้อเสีย : ยากที่จะแก้ไขรหัสดังกล่าวโดยไม่ต้อง IDE วาง "จุด" ไว้ท้ายความคิดเห็นที่เสร็จแล้ว ตัวอย่างเช่น: //Recognize wallpaper style. Here I wanted to add additional details int style = int.Parse(styleValue); //Apply style to image. …

26 coding-style  comments 

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

25 functional-programming  comments 

ปรากฏเป็นภาษาเดียวที่ไม่สามารถซ้อนความคิดเห็นได้ คุณมีทางออกที่ดีสำหรับปัญหานี้หรือไม่? วิธีแก้ปัญหาหนึ่งใน C / C ++ และ Java คือการใช้ความคิดเห็นบรรทัดเดียวเท่านั้น แต่มันเป็นไปไม่ได้ที่จะแสดงความคิดเห็นบล็อกขนาดใหญ่ ฉันกำลังเผชิญกับสิ่งนี้: </li><!-- <li><!-- Save --> ดังนั้นฉันต้องผ่านและแก้ไขความคิดเห็นด้วยตนเอง คุณช่วยแนะนำได้ไหมว่าเราควรจัดการเรื่องนี้ในหลาย ๆ ภาษา? ฉันไม่แน่ใจ แต่หลามอาจมีวิธีแก้ปัญหานี้ด้วย'''วิธีที่อาจรวมถึง#ความคิดเห็นในหลาม? `

23 java  c++  python  c  comments 

ล็อคแล้ว คำถามนี้ถูกล็อคเนื่องจากมีความคิดเห็นนอกหัวข้อจำนวนมาก ขณะนี้ไม่ยอมรับคำตอบหรือการโต้ตอบใหม่ ฉันมีการค้นหา แต่ไม่พบสิ่งที่ฉันกำลังมองหาโปรดเชื่อมโยงฉันหากคำถามนี้ถูกถามไปแล้ว เมื่อต้นเดือนที่โพสต์นี้ถูกสร้าง: http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/ โดยสรุปแล้วคุณเป็นโปรแกรมเมอร์ที่ไม่ดีถ้าคุณไม่เขียนความคิดเห็น ความคิดเห็นส่วนตัวของฉันคือรหัสควรเป็นคำอธิบายและส่วนใหญ่ไม่ต้องการความคิดเห็นยกเว้นว่าโค้ดไม่สามารถอธิบายตัวเองได้ ในตัวอย่างที่กำหนด // Get the extension off the image filename $pieces = explode('.', $image_name); $extension = array_pop($pieces); ผู้เขียนกล่าวว่ารหัสนี้ควรได้รับการแสดงความคิดเห็นความคิดเห็นส่วนตัวของฉันคือรหัสควรจะเรียกฟังก์ชั่นที่เป็นคำอธิบาย: $extension = GetFileExtension($image_filename); อย่างไรก็ตามในความคิดเห็นที่มีคนให้คำแนะนำนั้น: http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/comment-page-2/#comment-357130 ผู้เขียนตอบโดยกล่าวว่าผู้วิจารณ์คือ "หนึ่งในคนเหล่านั้น" คือโปรแกรมเมอร์ที่ไม่ดี ทุกคนมีความเห็นอย่างไรกับรหัสอธิบายตนเองเทียบกับรหัสความคิดเห็น?

22 coding-standards  comments 

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

21 anti-patterns  comments 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 7 ปีที่ผ่านมา การแสดงความคิดเห็นในปัจจุบันนั้นง่ายกว่าที่เคย ใน Java มีเทคนิคที่ดีในการเชื่อมความคิดเห็นไปยังคลาสและ Java IDEs สามารถสร้างเชลล์ความคิดเห็นให้คุณได้ดี ภาษาเช่น Clojure ช่วยให้คุณสามารถเพิ่มคำอธิบายของฟังก์ชันในโค้ดฟังก์ชันเองเป็นอาร์กิวเมนต์ อย่างไรก็ตามเรายังคงอยู่ในยุคที่มักมีความคิดเห็นล้าสมัยหรือไม่ดีเขียนโดยนักพัฒนาที่ดี - ฉันสนใจที่จะปรับปรุงความทนทานและประโยชน์ของความคิดเห็นของฉัน โดยเฉพาะฉันสนใจ Java / Clojure / Python ที่นี่ แต่คำตอบไม่จำเป็นต้องเฉพาะภาษา มีเทคนิคใด ๆ ที่เกิดขึ้นใหม่ที่ตรวจสอบความคิดเห็นและตรวจสอบความคิดเห็น "บอบบาง" โดยอัตโนมัติ (ตัวอย่างเช่นความคิดเห็นที่มีหมายเลขเวทย์มนตร์ประโยคที่ไม่สมบูรณ์ ฯลฯ ) หรือความคิดเห็นที่ไม่ถูกต้อง (ตัวอย่างเช่นการตรวจสอบตัวแปรที่สะกดผิด และที่สำคัญยิ่งกว่า: มี "นโยบายการแสดงความคิดเห็น" หรือกลยุทธ์ที่ยอมรับได้หรือไม่? มีคำแนะนำมากมายเกี่ยวกับวิธีการเขียนโค้ด - แต่จะมีวิธีการอย่างไรในการแสดงความคิดเห็น?

20 java  python  clojure  comments 

จากโครงการโอเพนซอร์สบางโครงการฉันรวบรวมสไตล์การเข้ารหัสต่อไปนี้ void someFunction(bool forget); void ourFunction() { someFunction(false /* forget */); } ฉันมีข้อสงสัยเสมอเกี่ยวกับความfalseหมายของที่นี่ มันหมายถึง "ลืม" หรือ "ลืม" อ้างถึงพารามิเตอร์ที่เกี่ยวข้อง (เช่นในกรณีข้างต้น) และ "false" มีไว้เพื่อลบล้างหรือไม่ มีการใช้รูปแบบใดบ่อยที่สุดและวิธีใดดีที่สุด (หรือวิธีที่ดีกว่า) เพื่อหลีกเลี่ยงความคลุมเครือ

19 coding-style  comments  boolean