See the original English version of this article here
สิ่งหนึ่งที่ควรต้องทำ เมื่อ Programmer/Developer เขียน Code ก็คือ การ Comment ลงใน Code ที่เขียน มีหลายคนที่อาจละเลย ไม่ค่อยให้ความสำคัญ ซึ่งสิ่งเหล่านี้อาจทำให้เกิดปัญหาในภายหลังได้ โดยเฉพาะเมื่อต้องทำงานเป็นทีม หรือ Code นั้นต้องมีการ Maintain แต่คำถามที่น่าสนใจก็คือ คุณ Comment Code ได้ดีหรือแย่แค่ไหน
Comment คืออะไร
Comment ก็คือ บรรทัดใน Source Code File ของคุณที่ Programmers/Developers คนอื่นๆ สามารถอ่านมันได้ แต่ Compilers และ Interpreters จะไม่สนใจพวกมัน (ไม่มองพวกมันเป็น Code)
แล้วประเด็นคืออะไร
โดยทั่วไป Code มักยากที่จะทำความเข้าใจ การเพิ่มข้อความบรรยายเข้าไป จะช่วยให้ Developer สามารถอธิบาย Code ที่พวกเขาเขียน ให้กับคนอื่นที่จะมา Maintain Code ในภายหลังได้เข้าใจ
หากคุณอยากรู้ว่า การไม่ Comment Code เป็นอย่างไร ลองดูได้จาก ตัวอย่างด้านล่าง:
Block ของ Code ที่คุณเห็นด้านบน จะเห็นได้ว่ามีการทำอะไรหลายๆ อย่าง แต่ผลก็คือ มันเป็นเรื่องยากสำหรับ Programmer ที่จะเข้าใจว่า Code เหล่านี้มันทำอะไรบ้าง
คราวนี้ลองมาดู Code ที่มี Comment กัน:
คงจะเห็นแล้วว่า Code ที่มีการใส่ Comment ไปด้วยมันจะช่วยให้เข้าใจได้ง่ายกว่า จริงไหม? เพราะมันจะช่วยอธิบายว่า Code กำลังทำอะไร(What) ขณะที่ตัว Code เองก็กำลังอธิบายถึงวิธีการว่ามันเกิดขึ้นได้อย่างไร (How) โดยทั่วไปแล้ว Developer มักชอบคิดถึงแต่ What โดยมักจะลืมคิดถึง How
ดังนั้น Comment ก็ช่วยให้เราให้อธิบาย Code ของเราให้เข้าใจง่ายขึ้น?
ใช่
ฟังดูแล้ว สิ่งนี้ก็น่าจะเป็นสิ่งที่ควรทำ?
แน่นอนว่า ใช่ แต่อย่างไรก็ตาม เรามีหลายวิธีในการอธิบายแนวคิดของเราภายใน Code และด้วยแนวคิดนี้ บางครั้ง Comment ก็อาจเป็นสิ่งที่แย่ที่สุดได้เช่นกัน
แล้วอะไรที่ทำให้ Comment ถึงกลายเป็นสิ่งที่แย่ล่ะ?
มันก็มีอยู่หลายอย่าง อย่างแรกก็คือ ไม่มีการรับประกันว่าจะมีคนอ่านมัน อันที่จริง Developer ส่วนใหญ่มักไม่ค่อยสนใจพวกมัน บางครั้งเครื่องมือต่างๆ ที่เราใช้ก็กลับไม่ช่วยเรา ลองดู Screen capture ของ WebStorm สิ ค่าสีที่ Default สำหรับ Comment มีสีเทาอ่อนๆ ซึ่งพอมองแล้วก็ไม่สะดุดและดึงดูดสายตาเลย
ทำไมเราถึงไม่เขียนแค่ Block ที่ชื่อว่า ‘โปรดอ่าน Comments’ ล่ะ?
นี่เป็นคำถามที่ดี เป็นเพราะคุณไม่สามารถเชื่อถือ Comment ที่คุณอ่านได้
Executable Code ที่คุณเขียน ถือเป็น Source ที่เป็นจริง ที่เรารู้ว่ามันเป็นจริง ก็เพราะเรากำลัง Run มันอยู่จริงๆ ยังไงล่ะ Comments ถือเป็น Source ที่เป็นทางเลือกของสิ่งที่เป็นจริง แต่ก็ไม่มีอะไรที่จะรับประกันมันจะเป็นจริงมากแค่ไหน
เช่นเดียวกับ System อื่นๆ ที่มี Source ที่เป็นจริงอยู่หลายแหล่ง เป็นเรื่องปกติที่ Developer จะ Update Source ของแหล่งหนึ่ง และลืมที่จะอ Update ของอีกแหล่งหนึ่ง คุณสามารถพูดอย่างจริงใจได้หรือไม่ว่า เมื่อคุณเปลี่ยนแปลงแก้ไข Code แล้ว คุณได้อ่าน Comment ต่างๆ ที่อยู่โดยรอบทั้งหมดเพื่อให้แน่ใจว่ามันยังคงถูกต้องอยู่?
เชื่อว่าคำตอบ น่าจะเป็น “ไม่” มันง่ายมากที่คุณจะลืมทำ ดังนั้น ควรทำให้แน่ใจว่า System ของคุณมี Source ที่เป็นจริงสักหนึ่งแหล่ง
งั้นเราก็พอจะยอมได้ว่า Comment ไม่ใช่สิ่งที่ Perfect นัก และคงไม่มีอะไรในโลกนี้ที่ Perfect ด้วยเช่นกัน
แล้วถ้าเรา Comment เพื่อที่จะอธิบายว่าตัวแปรเหล่านั้นคืออะไรล่ะ คุณกำลังบอกว่า มันไม่ดีสักเท่าไรที่จะอธิบายว่าตัวแปรของคุณมีไว้เพื่ออะไร ใช่ไหม?
การทำให้ชัดเจนว่า ตัวแปรนั้นมีไว้เพื่อทำอะไร ถือว่ามีความสำคัญมาก นั่นเป็นเหตุผลที่เราตั้งชื่อให้พวกมันยังไงล่ะ หากคุณตั้งชื่อตัวแปรที่มีความหมายชัดเจน คุณก็ไม่จำเป็นต้องใส่ Comment มันจะดีกว่าหากทุกๆ แห่งใน Code เป็นตัวแปรที่มีความหมาย คนที่จะ Maintain Code ของคุณจะได้รู้ว่า มันมีไว้เพื่อทำอะไร พวกเขาจะได้ไม่ต้องหยุดอ่าน Comment และอ้างอิงกลับไปที่คำนิยามของพวกมัน ลองเปรียบดูว่า Code ที่ 2 ดีกว่า Code อย่างไร จากตัวอย่างด้านล่างนี้
เราสามารถนำไปประยุกต์ใช้กับ Function ได้ด้วย ใช่หรือไม่?
แน่นอนว่า ใช่ ตั้งชื่อ Functions และ Parameters ของมันให้สื่อความหมายว่า มันทำอะไร หากคุณทำเช่นนั้นแล้ว คุณก็ไม่จำเป็นต้องใส่ Comment ในส่วนหัวของ Function ก็ได้
แล้ว Code ก่อนของคุณล่ะ Comment ของมันอธิบาย Blocks ของ Code ที่ทำงานร่วมกันเป็นอย่างดี ไม่สามารถช่วยได้จากการตั้งชื่อที่ดีเลยใช่ไหม?
ใช่แล้ว Code เพียงไม่กี่บรรทัด ที่ทำสิ่งหนึ่งร่วมกัน สามารถแยกออกเป็น Function ที่ถูกตั้งชื่อที่เหมาะสม เราลองไปดูกัน:
เห็นวิธีที่ Code สร้าง alien ซึ่งตอนนี้อยู่ใน Function ที่อธิบายถึงสิ่งที่มันทำไหม? มันเป็นอย่างเดียวกันกับ Stats Code เลย จะเห็นว่า Code ข้างต้นนั้น ไม่ต้องการคำอธิบายเพิ่มเติมเลย เพราะมันทำในสิ่งที่มันอธิบายออกมา
การใช้ Function ยังมีข้อได้เปรียบที่ซ่อนรายละเอียดไว้ ผู้ที่ Maintain ไม่ต้องกังวลเกี่ยวกับการทำงานของ Function หากมันไม่เกี่ยวข้องกับการเปลี่ยนแปลงในบางจุด มันทำให้ Code ง่ายในการทำความเข้าใจมากขึ้น
ผู้ที่ Maintain ไม่สามารถละเลยต่อชื่อ Function ได้ เหมือนอย่างที่พวกเขาอาจเพิกเฉยต่อ Comment ได้ ชื่อ Function ก็เป็น Code ดังนั้นพวกเขาต้องอ่าน Code พวกเขาต้องอ่านการเรียกใช้ Function และชื่อ Function
แล้วถ้าเราจำเป็นต้อง Optimize Code บางส่วน เราจะสามารถใช้ Comment ได้ใช่ไหม?
ใช่ สามารถใช้ได้
แต่ อ่านตรงนี้ก่อน
เราเป็น Software Engineer ซึ่งส่วนใหญ่มักมี Tools ต่างๆ ไว้ใช้งาน Comments ก็เป็น Tools เหมือนอย่าง Functions, เหมือนอย่างชื่อตัวแปร ไม่มี Tools ไหน ที่สามารถแก้ไขได้ทุกปัญหา ไม่มี Tools ไหน ที่ซ้ำซ้อนกันกับ Tools อื่นๆ ไปเสียทุกอย่าง เมื่อไม่สามารถปรับปรุง Code ผ่านการจัดโครงสร้างที่ทำให้สามารถเข้าใจได้แล้ว การใส่ Comment ก็ถือเป็นตัวเลือกที่ดีที่สุด
งั้น Comment ก็เป็นสิ่งที่ดีน่ะสิ?
ไม่หรอก เพราะหลายครั้งมันก็ห่วยแตก มี Comment มากมายที่เราเห็นๆ กันอยู่ ซึ่งหลายครั้งก็ไม่เหมาะที่จะใส่ลงไปเลย โดยเฉพาะอย่างยิ่งComment ที่ใช้เป็นข้อแก้ตัวสำหรับ:
ชื่อของ Function และ ตัวแปร ที่แย่ๆ (ไม่สื่อความหมาย)
Function ที่ยาวมากหรือมีความซับซ้อนมาก
แต่อย่างไรก็ตาม หลักการของการใส่ Comment ที่แย่ๆ ถือเป็นข้อคิดเห็นอย่างคร่าวๆ ไม่ได้มีความเจาะจงลงไปว่าแบบไหนถึงเรียกว่าแย่จริงๆ ดังนั้น การที่จะระบุว่า Comment ที่แย่คือแบบไหนนั้น มันก็ไม่ชัดเจนเช่นกัน ขึ้นอยู่กับหลากหลายบริบท เช่น ข้อกำหนดภายในทีม ความเชี่ยวชาญ/ประสบการณ์ของ Developer เป็นต้น แต่อย่างน้อย ตอนนี้คุณก็รู้ในบางหลักการแล้วว่า เมื่อไรที่ควรต้องใส่ หรือไม่จำเป็นต้องใส่ น่าจะทำให้คุณเขียน Code อย่างมีประสิทธิภาพมากยิ่งขึ้น
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการกว่า 28 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่
Source: https://medium.com/