Ellen Spertus จาก StackOverflow แนะนำถึงการเขียนคอมเมนต์โค้ด 9 ข้อ เพื่อการเขียนโค้ดที่ดีขึ้น พร้อมกับเตือนว่าโค้ดที่มีคอมเมนต์แย่ๆ นั้นแย่กว่าโค้ดที่ไม่มีคอมเมนต์เลยเสียอีก โดยกฎ 9 ข้อได้แก่
- อย่าเขียนซ้ำกับในโค้ด: หลายคนอาจจะเรียนมาว่ายิ่งคอมเมนต์โค้ดเยอะยิ่งดี สร้างนิสัยให้โปรแกรมเมอร์บางคนคอมเมนต์ระบุสิ่งที่เขียนในโค้ดอยู่แล้ว
- อย่าใช้คอมเมนต์เป็นข้ออ้างในการเขียนโค้ดแย่ๆ: โค้ดที่อ่านยากหลายครั้งแก้ไขได้ด้วยการตั้งชื่อตัวแปรให้สื่อถึงการใช้งานตั้งแต่แรก เช่นบางคนชอบตั้งชื่อตัวแปรเป็นอักษรตัวเดียว
- ถ้าอธิบายโค้ดด้วยคอมเมนต์ไม่ได้ อาจจะแปลว่าโค้ดแย่: บางครั้งคอมเมนต์ในโค้ดอาจจะบอกแค่ว่ามันยากเกินอธิบาย การที่โค้ดอธิบายไม่ได้เช่นนี้อาจจะแปลว่าเราควรปรับโค้ดใหม่ให้ตรงไปตรงมา
- อย่าปล่อยให้คอมเมนต์สร้างความสับสน: คอมเมนต์บางอย่างไม่ได้เกี่ยวอะไรกับโค้ด ทำให้คนอ่านงงว่าคนคอมเมนต์จะบอกอะไร
- พยายามอธิบายส่วนที่คนไม่ชิน: หากเห็นโค้ดที่คนอื่นมาอ่านแล้วน่าจะรู้สึกแปลก หรือโค้ดที่คนอาจจะรู้สึกว่าตัดทิ้งก็ได้ก็ควรเขียนคอมเมนต์ไว้ว่าโค้ดส่วนนั้นจำเป็นอย่างไร
- ใส่ที่มาของโค้ด: การใส่ลิงก์ที่มาของโค้ดช่วยให้คนอ่านรู้ว่าโค้ดนี้พยายามแก้ปัญหาอะไร และบางทีโค้ดในที่มาก็มีการปรับปรุงไปแล้วก็อาจจะนำมาปรับปรุงในโครงการด้วย
- ใส่ลิงก์อ้างอิง: บางครั้งเราอาจจะไม่ได้เอาโค้ดมาโดยตรง แต่อ้างอิงจากเอกสารมาตรฐาน การใส่ลิงก์ไว้ก็ช่วยให้คนอ่านรู้ว่าเราพยายามทำตามมาตรฐานใด และบางครั้งมาตรฐานก็มีการปรับปรุงเช่นกัน
- อ้างอิงถึงบั๊ก: หลายครั้งโค้ดที่กำลังพัฒนาเกิดจากการแก้ไขบั๊กก่อนหน้า ควรใส่คอมเมนต์อธิบายว่าโค้ดส่วนนั้นแก้ไขบั๊กอย่างไร หรือบางทีก็อ้างอิงหมายเลขบั๊กเข้าไปเลย
- เตือนว่ายังอิมพลีเมนต์ไม่เสร็จ: หลายโครงการมีฟีเจอร์ที่อิมพลีเมนต์ไว้ครึ่งๆ กลางๆ การใส่คอมเมนต์ TODO ค่อนข้างเป็นมาตรฐาน หรือให้ดีก็อ้างอิงถึง issue tracker ที่กำลังคุยกันถึงการแก้ไขโค้ดส่วนนั้นไว้เลย
คำแนะนำในการเขียนคอมเมนต์โค้ดนั้นมีหลากหลาย แต่แนวทางของ StackOverflow ก็นับว่าครอบคลุมกรณีส่วนใหญ่ โดยเฉพาะการใส่ที่มาในข้อ 6-8 ที่คำแนะนำบางที่ไม่ได้กล่าวถึงกันนัก
ที่มา - StackOverflow

คอมเมนต์ทุกบรรทัดโดยไม่จำเป็นทำให้โค้ดอ่านยากกว่าเดิม ตัวอย่างโดย Professional_Marxman
on
6-9 นี่คือดีเลย
btoy Sat, 25/12/2021 - 11:55
6-9 นี่คือดีเลย
ลบ '-' มันก็เป็นเลขที่ดีนะ
osmiumwo1f Sat, 25/12/2021 - 20:50
In reply to 6-9 นี่คือดีเลย by btoy
ลบ '-' มันก็เป็นเลขที่ดีนะ
เย้ย 555
btoy Sun, 26/12/2021 - 12:05
In reply to ลบ '-' มันก็เป็นเลขที่ดีนะ by osmiumwo1f
เย้ย 555
@TODO นี่ใช้ประจำเลย
itpcc Sat, 25/12/2021 - 12:50
@TODO นี่ใช้ประจำเลย ก่อนนอนแล้วชอบคิดถึง error ได้ก็ใส่ไว้ เช้ามาก็มา Ctrl + F แก้เอา
@see นี่ก็ประจำ บางทีเจอ magic number หรือ voodoo code ก็หามาใส่ไว้ ผ่านไปนานๆ กลับมาอ่านก็ช่วยได้พอสมควรเลย
มีบุคคลหนึ่ง จำชื่อไม่ได้แล้ว
big50000 Sat, 25/12/2021 - 13:42
มีบุคคลหนึ่ง จำชื่อไม่ได้แล้ว ได้กล่าวไว้ว่า
ก็เลยแทบไม่ได้อธิบายโค้ดเลย (นอกเหนือจาก TODO, NotImplemented หรือเขียน lib, API ไว้ใช้งาน) เน้นเขียนโค้ดให้เข้าใจง่ายไปเลยจะดีกว่า ส่วนไหนที่เป็นส่วน optimization แล้วค่อนข้างเข้าใจยากก็ค่อยอธิบายเอาตอนนั้น
แต่ถึงกระนั้น ก็ยังอยากแนะนำให้คนที่หัดเขียนโปรแกรมใหม่ ๆ ถ้ายังไม่คุ้นเคยก็เขียน comment บรรทัดที่ไม่เข้าใจไปก่อนว่ามันทำอะไร จำนวนจะน้อยจะเยอะก็ช่างมัน พอถึงเวลาที่เรามั่นใจแล้วว่าเราคุ้นเคยกับมันก็ค่อย ๆ ลดบรรทัด comment ลง จนกระทั่งไม่จำเป็นต้องเขียนอีกต่อไป
ไม่ใช่ผม
rattananen Sat, 25/12/2021 - 16:15
In reply to มีบุคคลหนึ่ง จำชื่อไม่ได้แล้ว by big50000
ไม่ใช่ผม แต่ผมก็มีความคิดแนวนี้อยู่
ที่จริงพวก syntax/ pattern ของภาษาต่างๆ มันออกแบบไว้เพื่อให้ dev สื่อสารกันอยู่แล้ว
อย่าง keyword พวก public private protected ของ OOP มันก็ไม่ได้มีไว้เพื่อ security อะไรเลย มีไว้เพื่อ hint คนอื่นมากว่า จะใช้ public ทั้ง program มันก็ไม่มีปัญหาอะไร
ยกเว้นภาษา GO นะครับ syntax นี้เหมือนจะตามอารมณ์คนสร้างมากไปหน่อย เปลี่ยนใจจะ export อะไรทีนี้แก้ยก project
ผมพยายามปฏิบัติตามแนวทางนี้อย
paween_a Sat, 25/12/2021 - 22:22
In reply to มีบุคคลหนึ่ง จำชื่อไม่ได้แล้ว by big50000
ผมพยายามปฏิบัติตามแนวทางนี้อยู่ มันก็พอไปได้นะ เพราะเราสามารถใช้ชื่อ function, variable ในการอธิบายแทน comment ได้อยู่แล้ว
และที่สำคัญคือมี unit test ที่เขียนอธิบายว่า code นี้มันคืออะไร ใช้งานอย่างไรอยู่
และที่สำคัญที่สุดคือ comment ไม่ได้เปลี่ยนตาม code นะ อย่าไปพึ่งมันมาก
ในแง่ logic ก็ใช่ครับ
lancaster Sun, 26/12/2021 - 17:44
In reply to มีบุคคลหนึ่ง จำชื่อไม่ได้แล้ว by big50000
ในแง่ logic ก็ใช่ครับ คือถ้าโค้ดเขียนไว้ดีแล้ว เรื่องพื้นฐานส่วนใหญ่มันไม่จำเป็นต้อง comment
แต่ภาพใหญ่กว่านั้น เช่น โค้ดส่วนนี้มีไว้เพื่อแก้ปัญหาอะไร ทำไมถึงเลือก approach นี้ (กรณีมีหลาย approach ที่ solve ปัญหาเดียวกันนี้ได้) รวมถึงอ้างอิงไปยังมาตรฐานหรือแนวทางที่เกี่ยวข้อง ซึ่งของพวกนี้แทบจะเป็นไปไม่ได้เลยที่จะอธิบายด้วยโค้ดอย่างเดียวครับ
อีกเหตุผลที่ดีพอๆ กันคือ tool
big50000 Sun, 26/12/2021 - 18:23
In reply to ในแง่ logic ก็ใช่ครับ by lancaster
อีกเหตุผลที่ดีพอๆ กันคือ tool ที่เลือกอาจไม่ได้ solve ทุกอย่าง ก็ต้องอธิบายในส่วนที่ implement เองเข้าไปด้วย
ผมว่า กฎข้อนึงที่ควรจะมีคือ
mr_tawan Sat, 25/12/2021 - 17:53
ผมว่า กฎข้อนึงที่ควรจะมีคือ "แก้โค๊ดแล้ว แก้คอมเมนท์ด้วย" เพราะหลาย ๆ ครั้งเราก็แก้โค้ดอย่างเดียวแล้วไม่ได้อ่านเลยว่าคอมเมนท์เขียนอะไรไว้ แล้วพอไม่ได้อ่านเราก็ไม่ได้แก้คอมเมนท์ ทำให้หลังจากนั้นคนมาอ่านทีหลังก็งงว่าตกลงโค๊ดหรือคอมเมนท์กันแน่ที่ถูก อะไรแบบนี้ครับ
เท่าที่ผมจำได้ mr_tawan
whitebigbird Mon, 27/12/2021 - 00:38
In reply to ผมว่า กฎข้อนึงที่ควรจะมีคือ by mr_tawan
เท่าที่ผมจำได้ mr_tawan เคยเป็นคนที่ไม่ชอบ comment ในโค้ดเอามากๆ
ใช่ครับ
mr_tawan Tue, 28/12/2021 - 17:06
In reply to เท่าที่ผมจำได้ mr_tawan by whitebigbird
ใช่ครับ อันนี้เป็นกฎรีวิวโค๊ดส่วนตัวผมเกี่ยวกับคอมเมนท์ครับ
นี่รีวิวโค้ดหรือข้อสอบภาษาอัง
whitebigbird Wed, 29/12/2021 - 10:55
In reply to ใช่ครับ by mr_tawan
นี่รีวิวโค้ดหรือข้อสอบภาษาอังกฤษฮะ
ผมเขียน COBOL เคยเจอ comment
pepporony Sat, 25/12/2021 - 18:33
ผมเขียน COBOL เคยเจอ comment block ในโปรแกรมนึงว่า
As of 1998, persons who understand this program are
Comment ต่อครับ
Shifter Mon, 27/12/2021 - 16:10
In reply to ผมเขียน COBOL เคยเจอ comment by pepporony
Comment ต่อครับ
Those have already left the company.
ใช่ครับ ส่วนใหญ่เป็นแบบนั้น
pepporony Tue, 28/12/2021 - 07:20
In reply to Comment ต่อครับ by Shifter
ใช่ครับ ส่วนใหญ่เป็นแบบนั้น บางคนก็ left this world ไปแล้ว