ตั้งค่า Auto-format และ Lint ให้โค้ดสวย ลดบั๊กตั้งแต่บรรทัดแรก

การเขียนโค้ดในโปรเจกต์เว็บ โดยเฉพาะสาย JavaScript และ TypeScript มักมีเรื่องเล็กๆ ที่กินเวลาทีมมากกว่าที่คิด เช่น การเว้นวรรค การใส่เครื่องหมาย ; หรือการจัดลำดับ import จนบางครั้งเสียเวลาถกเถียงกันมากกว่าการออกแบบฟีเจอร์จริงๆ

ทางออกที่ได้ผลคือปล่อยให้เครื่องมือช่วยจัดระเบียบโค้ดแทนมนุษย์ แล้วให้ทีมโฟกัสกับเรื่องสำคัญอย่างตรรกะและคุณภาพของระบบมากขึ้น เครื่องมือยอดนิยมที่มักใช้ร่วมกันมีทั้ง Prettier, ESLint, Husky, lint-staged และการตั้งค่าใน VS Code

ทำไมควรใช้ทั้ง Prettier และ ESLint

หลายคนสงสัยว่าทำไมต้องใช้ทั้งสองตัวพร้อมกัน คำตอบคือทั้งคู่ทำหน้าที่ต่างกันอย่างชัดเจน

• Prettier รับผิดชอบเรื่องรูปแบบโค้ด เช่น การเยื้องบรรทัด การเว้นวรรค และความสม่ำเสมอของหน้าตาโค้ด
• ESLint รับผิดชอบเรื่องกฎการเขียนโค้ด คุณภาพ และการช่วยตรวจจับความผิดพลาดที่อาจกลายเป็นบั๊ก

หากตั้งค่าให้ถูกต้อง ทั้งสองเครื่องมือจะไม่ตีกัน แต่จะช่วยกันคนละด้าน โดย Prettier ดูแลความสวยงาม ส่วน ESLint ดูแลมาตรฐานและความปลอดภัยของโค้ด

ชุดเครื่องมือพื้นฐานที่ควรมี

สำหรับโปรเจกต์ Node.js ชุดแพ็กเกจที่นิยมติดตั้งได้แก่

• prettier
• eslint
• eslint-config-prettier
• eslint-plugin-prettier

ถ้าเป็นโปรเจกต์ TypeScript มักเพิ่มแพ็กเกจดังนี้

• @typescript-eslint/parser
• @typescript-eslint/eslint-plugin

จุดสำคัญมากคือ eslint-config-prettier เพราะมันช่วยปิดกฎด้าน formatting ที่อาจชนกับ Prettier ทำให้ ESLint ไม่ต้องมายุ่งกับงานจัดรูปแบบ และหันไปโฟกัสที่คุณภาพโค้ดแทน

ตั้งค่าให้ทำงานอัตโนมัติใน VS Code

เมื่อเลือกเครื่องมือแล้ว ขั้นตอนต่อไปคือทำให้มันทำงานอัตโนมัติขณะเขียนโค้ด เพื่อให้ผลลัพธ์เกิดขึ้นทันทีตั้งแต่บรรทัดแรก

สิ่งที่ควรตั้งค่าใน VS Code ได้แก่

• เปิดใช้งาน Format on Save
• ตั้ง Default Formatter เป็น Prettier
• เลือกให้ format เฉพาะไฟล์ที่เกี่ยวข้อง เช่น js, ts, json, md
• เปิด Code Actions on Save เพื่อให้ ESLint ช่วย fix สิ่งที่แก้ไขอัตโนมัติได้

ข้อดีของการตั้งค่าแบบนี้คือทุกครั้งที่กดบันทึกไฟล์ โค้ดจะถูกจัดรูปแบบและแก้ปัญหาเบื้องต้นให้ทันที ช่วยลดการสะสมของโค้ดสกปรกโดยไม่ต้องคอยกลับมาเก็บงานภายหลัง

ป้องกันปัญหาก่อนเข้า Repository ด้วย Husky และ lint-staged

ต่อให้ตั้งค่าใน editor ดีแค่ไหน ก็ยังมีโอกาสที่บางไฟล์จะหลุดรอดเข้า repository โดยไม่ผ่านการตรวจสอบ โดยเฉพาะเมื่อสมาชิกทีมใช้เครื่องมือหรือสภาพแวดล้อมต่างกัน

วิธีที่นิยมใช้คือเพิ่ม Husky และ lint-staged เพื่อทำงานก่อน commit

แนวทางคือให้รันเฉพาะไฟล์ที่มีการเปลี่ยนแปลง เช่น

• prettier --write
• eslint --fix

บางทีมอาจเพิ่มการรัน test เฉพาะส่วน หรือ type check เฉพาะไฟล์ที่เกี่ยวข้องด้วย วิธีนี้ช่วยลดโอกาสที่โค้ดคุณภาพต่ำหรือรูปแบบไม่ตรงมาตรฐานจะหลุดเข้า repo ได้มาก

เทคนิคใช้งานจริงเพื่อลดบั๊กอย่างเห็นผล

เมื่อเริ่มใช้งานแล้ว ยังมีแนวคิดสำคัญที่ช่วยให้ระบบ lint และ format สร้างผลลัพธ์ได้ดียิ่งขึ้น

1. อย่าปล่อย warning กองสะสม

ควรตั้งเป้าให้ warning เป็นศูนย์ หรืออย่างน้อยควบคุมไม่ให้เพิ่มขึ้นเรื่อยๆ เพราะ warning ที่ค้างอยู่มักทำให้ทีมชินชาและมองข้ามปัญหาที่สำคัญจริง

2. แยกกฎเป็นชั้นๆ

กฎที่เกี่ยวกับคุณภาพและความเสี่ยงต่อบั๊กควรตั้งเป็นระดับ error ส่วนกฎด้านสไตล์ควรปล่อยให้ Prettier จัดการ เพื่อลดความซ้ำซ้อนและความขัดแย้งของเครื่องมือ

3. จัดการ import อย่างจริงจัง

ปลั๊กอินอย่าง eslint-plugin-import ช่วยตรวจจับปัญหาที่หลายทีมมองข้าม เช่น

• import ซ้ำ
• import ที่ไม่ได้ใช้งาน
• การอ้างอิงแบบวนลูปของ dependency

4. เข้มงวดกับตัวแปรที่ไม่ได้ใช้

ตัวแปรหรือพารามิเตอร์ที่ประกาศไว้แต่ไม่ถูกใช้งาน มักเป็นสัญญาณว่าการ refactor ยังไม่สมบูรณ์ หรือมีตรรกะบางส่วนที่ตกหล่นไปแล้ว การจับจุดนี้เร็วช่วยให้โค้ดสะอาดและลดความสับสนในระยะยาว

ตัวอย่างบั๊กที่ Lint ช่วยจับได้เร็ว

เครื่องมือ lint ไม่ได้ช่วยแค่เรื่องความเรียบร้อย แต่ยังช่วยจับข้อผิดพลาดเล็กๆ ที่อาจกลายเป็นบั๊กจริงในระบบได้อย่างรวดเร็ว เช่น

• ลืม await ในฟังก์ชัน async
• ใช้ == แทน ===
• ใช้ตัวแปรก่อนประกาศในบางกรณี
• เขียนเงื่อนไขผิด เช่น if (a = b)

ข้อผิดพลาดเหล่านี้มักเกิดจากการพิมพ์พลาดหรือความเคยชิน และหากไม่มีตัวช่วยตรวจ อาจหลุดไปถึงขั้น review หรือ production ได้

ผลลัพธ์ที่ทีมมักเห็นหลังตั้งค่าครบ

เมื่อระบบ Auto-format และ Lint ทำงานครบวงจรแล้ว ผลลัพธ์ที่มักเกิดขึ้นมีชัดเจนมาก ได้แก่

• Pull Request อ่านง่ายขึ้นทันที
• การรีวิวเร็วขึ้น เพราะไม่ต้องเสียเวลาคอมเมนต์เรื่องสไตล์โค้ด
• บั๊กจากความผิดพลาดเล็กๆ ลดลงอย่างเห็นได้ชัด
• สมาชิกใหม่ในทีมเริ่มต้นด้วยมาตรฐานเดียวกันตั้งแต่วันแรก

สิ่งเหล่านี้ไม่เพียงช่วยประหยัดเวลา แต่ยังทำให้ทีมทำงานร่วมกันได้ลื่นไหลและขยายโปรเจกต์ได้ง่ายขึ้น

เช็กลิสต์ก่อนนำไปใช้จริง

ก่อนใช้งานในโปรเจกต์จริง ควรตรวจสอบให้แน่ใจว่าองค์ประกอบสำคัญทำงานครบถ้วน

• Prettier รันผ่าน CLI ได้
• ESLint รันผ่าน CLI ได้ และสามารถ fix ได้
• เมื่อกดบันทึกใน VS Code แล้วมีทั้ง format และ fix
• ตอน commit แล้ว lint-staged ทำงานจริง
• ใน CI มีการรัน lint และ test ซ้ำเพื่อกันข้อผิดพลาดหลุดรอด

สรุป

การตั้งค่า Auto-format และ Lint ไม่ใช่แค่การทำให้โค้ดดูสวย แต่คือการสร้างกระบวนการทำงานที่ช่วยลดงานจุกจิก ลดข้อถกเถียงในทีม และป้องกันบั๊กตั้งแต่ต้นทาง หากเริ่มตั้งค่าให้ถูกตั้งแต่วันนี้ คุณจะได้ทั้งโค้ดที่อ่านง่าย รีวิวง่าย และคุณภาพที่ดีขึ้นตั้งแต่ไฟล์แรกของโปรเจกต์