Tags:
Node Thumbnail

Ellen Spertus จาก StackOverflow แนะนำถึงการเขียนคอมเมนต์โค้ด 9 ข้อ เพื่อการเขียนโค้ดที่ดีขึ้น พร้อมกับเตือนว่าโค้ดที่มีคอมเมนต์แย่ๆ นั้นแย่กว่าโค้ดที่ไม่มีคอมเมนต์เลยเสียอีก โดยกฎ 9 ข้อได้แก่

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

คำแนะนำในการเขียนคอมเมนต์โค้ดนั้นมีหลากหลาย แต่แนวทางของ StackOverflow ก็นับว่าครอบคลุมกรณีส่วนใหญ่ โดยเฉพาะการใส่ที่มาในข้อ 6-8 ที่คำแนะนำบางที่ไม่ได้กล่าวถึงกันนัก

ที่มา - StackOverflow

No Description

คอมเมนต์ทุกบรรทัดโดยไม่จำเป็นทำให้โค้ดอ่านยากกว่าเดิม ตัวอย่างโดย Professional_Marxman

Get latest news from Blognone

Comments

By: btoy
ContributorAndroidWindows
on 25 December 2021 - 11:55 #1235447
btoy's picture

6-9 นี่คือดีเลย


..: เรื่อยไป

By: osmiumwo1f
ContributorWindows PhoneWindows
on 25 December 2021 - 20:50 #1235489 Reply to:1235447
osmiumwo1f's picture

ลบ '-' มันก็เป็นเลขที่ดีนะ

By: btoy
ContributorAndroidWindows
on 26 December 2021 - 12:05 #1235521 Reply to:1235489
btoy's picture

เย้ย​ 555


..: เรื่อยไป

By: itpcc
ContributoriPhoneRed HatUbuntu
on 25 December 2021 - 12:50 #1235454
itpcc's picture

@TODO นี่ใช้ประจำเลย ก่อนนอนแล้วชอบคิดถึง error ได้ก็ใส่ไว้ เช้ามาก็มา Ctrl + F แก้เอา

@see นี่ก็ประจำ บางทีเจอ magic number หรือ voodoo code ก็หามาใส่ไว้ ผ่านไปนานๆ กลับมาอ่านก็ช่วยได้พอสมควรเลย


บล็อกส่วนตัวที่อัพเดตตามอารมณ์และความขยัน :P

By: big50000
AndroidSUSEUbuntu
on 25 December 2021 - 13:42 #1235460
big50000's picture

มีบุคคลหนึ่ง จำชื่อไม่ได้แล้ว ได้กล่าวไว้ว่า

โค้ดที่ดี ไม่จำเป็นต้องอธิบาย

ก็เลยแทบไม่ได้อธิบายโค้ดเลย (นอกเหนือจาก TODO, NotImplemented หรือเขียน lib, API ไว้ใช้งาน) เน้นเขียนโค้ดให้เข้าใจง่ายไปเลยจะดีกว่า ส่วนไหนที่เป็นส่วน optimization แล้วค่อนข้างเข้าใจยากก็ค่อยอธิบายเอาตอนนั้น

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

By: rattananen
AndroidWindows
on 25 December 2021 - 16:15 #1235472 Reply to:1235460

ไม่ใช่ผม แต่ผมก็มีความคิดแนวนี้อยู่
ที่จริงพวก syntax/ pattern ของภาษาต่างๆ มันออกแบบไว้เพื่อให้ dev สื่อสารกันอยู่แล้ว
อย่าง keyword พวก public private protected ของ OOP มันก็ไม่ได้มีไว้เพื่อ security อะไรเลย มีไว้เพื่อ hint คนอื่นมากว่า จะใช้ public ทั้ง program มันก็ไม่มีปัญหาอะไร

ยกเว้นภาษา GO นะครับ syntax นี้เหมือนจะตามอารมณ์คนสร้างมากไปหน่อย เปลี่ยนใจจะ export อะไรทีนี้แก้ยก project

By: paween_a
Android
on 25 December 2021 - 22:22 #1235500 Reply to:1235460
paween_a's picture

ผมพยายามปฏิบัติตามแนวทางนี้อยู่ มันก็พอไปได้นะ เพราะเราสามารถใช้ชื่อ function, variable ในการอธิบายแทน comment ได้อยู่แล้ว

และที่สำคัญคือมี unit test ที่เขียนอธิบายว่า code นี้มันคืออะไร ใช้งานอย่างไรอยู่

และที่สำคัญที่สุดคือ comment ไม่ได้เปลี่ยนตาม code นะ อย่าไปพึ่งมันมาก

By: lancaster
Contributor
on 26 December 2021 - 17:44 #1235536 Reply to:1235460

ในแง่ logic ก็ใช่ครับ คือถ้าโค้ดเขียนไว้ดีแล้ว เรื่องพื้นฐานส่วนใหญ่มันไม่จำเป็นต้อง comment

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

By: big50000
AndroidSUSEUbuntu
on 26 December 2021 - 18:23 #1235538 Reply to:1235536
big50000's picture

อีกเหตุผลที่ดีพอๆ กันคือ tool ที่เลือกอาจไม่ได้ solve ทุกอย่าง ก็ต้องอธิบายในส่วนที่ implement เองเข้าไปด้วย

By: mr_tawan
ContributoriPhoneAndroidWindows
on 25 December 2021 - 17:53 #1235477
mr_tawan's picture

ผมว่า กฎข้อนึงที่ควรจะมีคือ "แก้โค๊ดแล้ว แก้คอมเมนท์ด้วย" เพราะหลาย ๆ ครั้งเราก็แก้โค้ดอย่างเดียวแล้วไม่ได้อ่านเลยว่าคอมเมนท์เขียนอะไรไว้ แล้วพอไม่ได้อ่านเราก็ไม่ได้แก้คอมเมนท์ ทำให้หลังจากนั้นคนมาอ่านทีหลังก็งงว่าตกลงโค๊ดหรือคอมเมนท์กันแน่ที่ถูก อะไรแบบนี้ครับ


  • 9tawan.net บล็อกส่วนตัวฮับ
By: whitebigbird
Contributor
on 27 December 2021 - 00:38 #1235551 Reply to:1235477
whitebigbird's picture

เท่าที่ผมจำได้ mr_tawan เคยเป็นคนที่ไม่ชอบ comment ในโค้ดเอามากๆ

By: mr_tawan
ContributoriPhoneAndroidWindows
on 28 December 2021 - 17:06 #1235636 Reply to:1235551
mr_tawan's picture

ใช่ครับ อันนี้เป็นกฎรีวิวโค๊ดส่วนตัวผมเกี่ยวกับคอมเมนท์ครับ

  1. ถ้าไม่มีความจำเป็นอย่าเขียน
  2. ถ้ามีความจำเป็นที่จะต้องเขียน ให้ทบทวนความจำเป็นที่ว่านั่นใหม่
  3. เหมือนกับ 2.
  4. เหมือนกับ 3.
  5. ถ้ามั่นใจว่าต้องเขียนจริง ๆ กลับไปอ่านข้อ 2. ใหม่
  6. ถึงจุดนี้ถ้ายังคิดว่าต้องเขียนจริง ๆ ก็เขียนซะ เขียนให้อ่านให้รู้เรื่อง เขียนไว้ด้วยว่าเขียนทำไม และเขียนให้ถูกแกรมม่า (แกรมม่าผิดก็ไม่ให้ผ่าน)

  • 9tawan.net บล็อกส่วนตัวฮับ
By: whitebigbird
Contributor
on 29 December 2021 - 10:55 #1235661 Reply to:1235636
whitebigbird's picture

นี่รีวิวโค้ดหรือข้อสอบภาษาอังกฤษฮะ

By: pepporony
ContributorAndroid
on 25 December 2021 - 18:33 #1235482

ผมเขียน COBOL เคยเจอ comment block ในโปรแกรมนึงว่า

As of 1998, persons who understand this program are

  1. Name
  2. Name
By: Shifter on 27 December 2021 - 16:10 #1235587 Reply to:1235482

Comment ต่อครับ
Those have already left the company.

By: pepporony
ContributorAndroid
on 28 December 2021 - 07:20 #1235609 Reply to:1235587

ใช่ครับ ส่วนใหญ่เป็นแบบนั้น บางคนก็ left this world ไปแล้ว