Ellen Spertus จาก StackOverflow แนะนำถึงการเขียนคอมเมนต์โค้ด 9 ข้อ เพื่อการเขียนโค้ดที่ดีขึ้น พร้อมกับเตือนว่าโค้ดที่มีคอมเมนต์แย่ๆ นั้นแย่กว่าโค้ดที่ไม่มีคอมเมนต์เลยเสียอีก โดยกฎ 9 ข้อได้แก่
- อย่าเขียนซ้ำกับในโค้ด: หลายคนอาจจะเรียนมาว่ายิ่งคอมเมนต์โค้ดเยอะยิ่งดี สร้างนิสัยให้โปรแกรมเมอร์บางคนคอมเมนต์ระบุสิ่งที่เขียนในโค้ดอยู่แล้ว
- อย่าใช้คอมเมนต์เป็นข้ออ้างในการเขียนโค้ดแย่ๆ: โค้ดที่อ่านยากหลายครั้งแก้ไขได้ด้วยการตั้งชื่อตัวแปรให้สื่อถึงการใช้งานตั้งแต่แรก เช่นบางคนชอบตั้งชื่อตัวแปรเป็นอักษรตัวเดียว
- ถ้าอธิบายโค้ดด้วยคอมเมนต์ไม่ได้ อาจจะแปลว่าโค้ดแย่: บางครั้งคอมเมนต์ในโค้ดอาจจะบอกแค่ว่ามันยากเกินอธิบาย การที่โค้ดอธิบายไม่ได้เช่นนี้อาจจะแปลว่าเราควรปรับโค้ดใหม่ให้ตรงไปตรงมา
- อย่าปล่อยให้คอมเมนต์สร้างความสับสน: คอมเมนต์บางอย่างไม่ได้เกี่ยวอะไรกับโค้ด ทำให้คนอ่านงงว่าคนคอมเมนต์จะบอกอะไร
- พยายามอธิบายส่วนที่คนไม่ชิน: หากเห็นโค้ดที่คนอื่นมาอ่านแล้วน่าจะรู้สึกแปลก หรือโค้ดที่คนอาจจะรู้สึกว่าตัดทิ้งก็ได้ก็ควรเขียนคอมเมนต์ไว้ว่าโค้ดส่วนนั้นจำเป็นอย่างไร
- ใส่ที่มาของโค้ด: การใส่ลิงก์ที่มาของโค้ดช่วยให้คนอ่านรู้ว่าโค้ดนี้พยายามแก้ปัญหาอะไร และบางทีโค้ดในที่มาก็มีการปรับปรุงไปแล้วก็อาจจะนำมาปรับปรุงในโครงการด้วย
- ใส่ลิงก์อ้างอิง: บางครั้งเราอาจจะไม่ได้เอาโค้ดมาโดยตรง แต่อ้างอิงจากเอกสารมาตรฐาน การใส่ลิงก์ไว้ก็ช่วยให้คนอ่านรู้ว่าเราพยายามทำตามมาตรฐานใด และบางครั้งมาตรฐานก็มีการปรับปรุงเช่นกัน
- อ้างอิงถึงบั๊ก: หลายครั้งโค้ดที่กำลังพัฒนาเกิดจากการแก้ไขบั๊กก่อนหน้า ควรใส่คอมเมนต์อธิบายว่าโค้ดส่วนนั้นแก้ไขบั๊กอย่างไร หรือบางทีก็อ้างอิงหมายเลขบั๊กเข้าไปเลย
- เตือนว่ายังอิมพลีเมนต์ไม่เสร็จ: หลายโครงการมีฟีเจอร์ที่อิมพลีเมนต์ไว้ครึ่งๆ กลางๆ การใส่คอมเมนต์ TODO ค่อนข้างเป็นมาตรฐาน หรือให้ดีก็อ้างอิงถึง issue tracker ที่กำลังคุยกันถึงการแก้ไขโค้ดส่วนนั้นไว้เลย
คำแนะนำในการเขียนคอมเมนต์โค้ดนั้นมีหลากหลาย แต่แนวทางของ StackOverflow ก็นับว่าครอบคลุมกรณีส่วนใหญ่ โดยเฉพาะการใส่ที่มาในข้อ 6-8 ที่คำแนะนำบางที่ไม่ได้กล่าวถึงกันนัก
ที่มา - StackOverflow
คอมเมนต์ทุกบรรทัดโดยไม่จำเป็นทำให้โค้ดอ่านยากกว่าเดิม ตัวอย่างโดย Professional_Marxman
Comments
6-9 นี่คือดีเลย
..: เรื่อยไป
ลบ '-' มันก็เป็นเลขที่ดีนะ
เย้ย 555
..: เรื่อยไป
@TODO นี่ใช้ประจำเลย ก่อนนอนแล้วชอบคิดถึง error ได้ก็ใส่ไว้ เช้ามาก็มา Ctrl + F แก้เอา
@see นี่ก็ประจำ บางทีเจอ magic number หรือ voodoo code ก็หามาใส่ไว้ ผ่านไปนานๆ กลับมาอ่านก็ช่วยได้พอสมควรเลย
บล็อกส่วนตัวที่อัพเดตตามอารมณ์และความขยัน :P
มีบุคคลหนึ่ง จำชื่อไม่ได้แล้ว ได้กล่าวไว้ว่า
ก็เลยแทบไม่ได้อธิบายโค้ดเลย (นอกเหนือจาก TODO, NotImplemented หรือเขียน lib, API ไว้ใช้งาน) เน้นเขียนโค้ดให้เข้าใจง่ายไปเลยจะดีกว่า ส่วนไหนที่เป็นส่วน optimization แล้วค่อนข้างเข้าใจยากก็ค่อยอธิบายเอาตอนนั้น
แต่ถึงกระนั้น ก็ยังอยากแนะนำให้คนที่หัดเขียนโปรแกรมใหม่ ๆ ถ้ายังไม่คุ้นเคยก็เขียน comment บรรทัดที่ไม่เข้าใจไปก่อนว่ามันทำอะไร จำนวนจะน้อยจะเยอะก็ช่างมัน พอถึงเวลาที่เรามั่นใจแล้วว่าเราคุ้นเคยกับมันก็ค่อย ๆ ลดบรรทัด comment ลง จนกระทั่งไม่จำเป็นต้องเขียนอีกต่อไป
ไม่ใช่ผม แต่ผมก็มีความคิดแนวนี้อยู่
ที่จริงพวก syntax/ pattern ของภาษาต่างๆ มันออกแบบไว้เพื่อให้ dev สื่อสารกันอยู่แล้ว
อย่าง keyword พวก public private protected ของ OOP มันก็ไม่ได้มีไว้เพื่อ security อะไรเลย มีไว้เพื่อ hint คนอื่นมากว่า จะใช้ public ทั้ง program มันก็ไม่มีปัญหาอะไร
ยกเว้นภาษา GO นะครับ syntax นี้เหมือนจะตามอารมณ์คนสร้างมากไปหน่อย เปลี่ยนใจจะ export อะไรทีนี้แก้ยก project
ผมพยายามปฏิบัติตามแนวทางนี้อยู่ มันก็พอไปได้นะ เพราะเราสามารถใช้ชื่อ function, variable ในการอธิบายแทน comment ได้อยู่แล้ว
และที่สำคัญคือมี unit test ที่เขียนอธิบายว่า code นี้มันคืออะไร ใช้งานอย่างไรอยู่
และที่สำคัญที่สุดคือ comment ไม่ได้เปลี่ยนตาม code นะ อย่าไปพึ่งมันมาก
ในแง่ logic ก็ใช่ครับ คือถ้าโค้ดเขียนไว้ดีแล้ว เรื่องพื้นฐานส่วนใหญ่มันไม่จำเป็นต้อง comment
แต่ภาพใหญ่กว่านั้น เช่น โค้ดส่วนนี้มีไว้เพื่อแก้ปัญหาอะไร ทำไมถึงเลือก approach นี้ (กรณีมีหลาย approach ที่ solve ปัญหาเดียวกันนี้ได้) รวมถึงอ้างอิงไปยังมาตรฐานหรือแนวทางที่เกี่ยวข้อง ซึ่งของพวกนี้แทบจะเป็นไปไม่ได้เลยที่จะอธิบายด้วยโค้ดอย่างเดียวครับ
อีกเหตุผลที่ดีพอๆ กันคือ tool ที่เลือกอาจไม่ได้ solve ทุกอย่าง ก็ต้องอธิบายในส่วนที่ implement เองเข้าไปด้วย
ผมว่า กฎข้อนึงที่ควรจะมีคือ "แก้โค๊ดแล้ว แก้คอมเมนท์ด้วย" เพราะหลาย ๆ ครั้งเราก็แก้โค้ดอย่างเดียวแล้วไม่ได้อ่านเลยว่าคอมเมนท์เขียนอะไรไว้ แล้วพอไม่ได้อ่านเราก็ไม่ได้แก้คอมเมนท์ ทำให้หลังจากนั้นคนมาอ่านทีหลังก็งงว่าตกลงโค๊ดหรือคอมเมนท์กันแน่ที่ถูก อะไรแบบนี้ครับ
เท่าที่ผมจำได้ mr_tawan เคยเป็นคนที่ไม่ชอบ comment ในโค้ดเอามากๆ
ใช่ครับ อันนี้เป็นกฎรีวิวโค๊ดส่วนตัวผมเกี่ยวกับคอมเมนท์ครับ
นี่รีวิวโค้ดหรือข้อสอบภาษาอังกฤษฮะ
ผมเขียน COBOL เคยเจอ comment block ในโปรแกรมนึงว่า
As of 1998, persons who understand this program are
Comment ต่อครับ
Those have already left the company.
ใช่ครับ ส่วนใหญ่เป็นแบบนั้น บางคนก็ left this world ไปแล้ว