หลักการ Clean Code สำหรับ FiveM Script Developer

"มันทำงานได้" ไม่ใช่มาตรฐานสุดท้ายของโค้ดที่ดี — โค้ดถูกอ่านบ่อยกว่าที่มันถูกเขียน และ FiveM script ที่ดีต้องสื่อสารความหมายได้ชัดเจนสำหรับคนที่จะอ่านมันในอนาคต (และคนนั้นมักคือตัวคุณเอง 6 เดือนต่อมา)

---

หลักการที่ 1: ชื่อควรสื่อความหมาย

สิ่งที่แยก code ที่ดีออกจาก code ที่ไม่ดีบ่อยครั้งคือการตั้งชื่อ — ชื่อตัวแปร, ชื่อ function, ชื่อ event ควรบอกได้ทันทีว่า "มันคืออะไร" และ "มันทำอะไร"

ชื่อที่ดีทำให้ไม่ต้องมี comment อธิบาย ชื่อที่ไม่ดีต้องการ comment ทุกบรรทัด แต่ comment ที่แท้จริงที่สุดคือโค้ดที่อ่านแล้วเข้าใจเองได้

ใน FiveM สิ่งนี้สำคัญมากในเรื่อง event naming — ถ้า event ชื่อ myEvent มันบอกอะไรไม่ได้เลย แต่ถ้าชื่อ server:createLicense ทุกคนที่เห็นรู้ทันทีว่ามันทำอะไร

---

หลักการที่ 2: Function ทำสิ่งเดียว

Function ที่ดีทำสิ่งเดียว — ทำมันให้ดี และตั้งชื่อให้ชัดเจนว่าทำอะไร

ปัญหาที่พบบ่อยใน FiveM script คือ function ยักษ์ใหญ่ที่ทำทุกอย่างในที่เดียว — เช็ค permission, ดึงข้อมูลจาก database, คำนวณ business logic, อัพเดท UI, และส่ง notification ทั้งหมดใน function เดียว

Function แบบนี้ทดสอบยาก แก้ bug ยาก และทำความเข้าใจยาก เมื่อถึงเวลาที่ต้องเปลี่ยน logic บางส่วน ต้องระวังว่าจะกระทบส่วนอื่นที่อยู่ใน function เดียวกันไหม

แบ่ง function ใหญ่ออกเป็น function เล็กๆ หลายตัวที่มีชื่อชัดเจน — โค้ดที่ได้จะยาวขึ้น แต่อ่านง่ายกว่าและแก้ไขได้โดยไม่ต้องกลัวว่าจะกระทบส่วนที่ไม่ต้องการ

---

หลักการที่ 3: อย่าทิ้ง Dead Code ไว้

"Dead code" คือโค้ดที่ถูก comment out ไว้, function ที่ไม่มีใครเรียกใช้, หรือ variable ที่ประกาศแต่ไม่เคยใช้

ใน FiveM script เห็นบ่อยมากในรูปแบบของบรรทัดโค้ดเก่าที่ถูก comment ออกแล้วทิ้งไว้เป็น "อาจจะใช้ภายหลัง" — แต่ภายหลังนั้นไม่มาถึง และ comment นั้นอยู่ตรงนั้นมา 2 ปีแล้ว

Dead code สร้างความสับสน — คนที่อ่านโค้ดไม่รู้ว่า "บรรทัดนี้ comment ออกเพราะ bug? หรือเพราะไม่ได้ใช้แล้ว? หรือเพราะกำลังจะใช้?" ถ้าไม่ได้ใช้แล้ว — ลบทิ้ง Git เก็บ history ไว้ให้อยู่แล้ว

---

หลักการที่ 4: ค่า Magic Number ต้องมีชื่อ

Magic number คือตัวเลขที่ปรากฏใน code โดยไม่มีการอธิบายว่าหมายถึงอะไร

ใน FiveM script เห็นบ่อยในรูปแบบ timeout values, max player counts, coordinates, หรือ item weights — ตัวเลขที่ถูกใส่ตรงๆ โดยไม่มีชื่อ

ปัญหาคือ 3 เดือนต่อมาไม่มีใครรู้ว่าตัวเลขนั้นมาจากไหนและทำไมถึงเป็นเลขนั้น ทางออกคือให้ค่าพวกนี้มีชื่อในรูปแบบ constant หรือ config — ทั้งเพื่อความชัดเจนและเพื่อให้แก้ไขได้ง่ายในอนาคต

---

หลักการที่ 5: จัดการ Error อย่างตั้งใจ

Error handling ที่ไม่ดีมีสองรูปแบบสุดโต่ง — ละเลยทั้งหมดและปล่อยให้ crash, หรือ catch ทุกอย่างแล้วเงียบ

ทั้งสองแบบเป็นปัญหา — แบบแรกทำให้ server crash แบบที่สองซ่อน bug ไว้จนกว่าจะแสดงออกมาในรูปแบบที่แปลกประหลาดกว่าเดิม

Error handling ที่ดีใน FiveM script ต้องตอบคำถามสามข้อ: รู้ได้ไงว่าเกิด error? บันทึก error นั้นไว้ที่ไหน? และ user (หรือ server) จะได้รับ feedback อะไรเมื่อเกิด error?

---

หลักการที่ 6: Consistency ตลอดทั้ง Codebase

ใน project ที่มีคนพัฒนาหลายคน ปัญหาที่พบบ่อยคือแต่ละคนเขียนในสไตล์ที่ต่างกัน — บางคนใช้ snake_case, บางคนใช้ camelCase, บางคนตั้งชื่อ event แบบหนึ่ง บางคนแบบอื่น

Inconsistency สะสมทำให้โค้ดอ่านยากขึ้นเรื่อยๆ และเพิ่มโอกาสเกิด bug จากความสับสน ตัวอย่างเช่น event ชื่อเดียวกันถูกเรียกใช้ต่างกันในคนละไฟล์

การแก้ไขคือ กำหนด style guide ให้ทั้ง team และยึดถือมัน แม้จะยืดหยุ่นได้บ้างในรายละเอียด แต่ core conventions ควร consistent ตลอด

---

Clean Code ไม่ใช่ Perfectionism

สิ่งสำคัญที่ต้องจำคือ clean code ไม่ได้แปลว่า "perfect code" — มันแปลว่าโค้ดที่คนอื่น (และตัวคุณเอง) สามารถทำงานด้วยได้อย่างมีประสิทธิภาพ

There's no need to wait for the code to be perfect before deploying — but there should be minimum standards that make everyone on the team. "Read and understand" and "Edit and don't be afraid"

Invest 20% of your time cleaning up code after a feature works. And you'll save even more time maintaining it.