เรื่องที่ถกเถียงกันประจำสำหรับการเขียน code ประกอบไปด้วย

  • Tab vs Space ใช้อะไรดี ?
  • ใช้ 2 หรือ 4 space แทน Tab หรือไม่ ?
  • เขียน {} หรือไม่ ?
  • เขียน { ในบรรทัดไหน ?
  • Naming convention เป็นอย่างไร  camel case หรือ snake case ?
  • ตั้งชื่อต่าง ๆ เป็นอย่างไร ?
  • ถ้าเขียน test จะตั้งชื่ออย่างไรดี ?

สิ่งที่สำคัญมาก ๆ สำหรับทีมพัฒนาคือ
code ที่เขียนมันอ่านง่ายเข้าใจง่ายหรือไม่ ?
คนที่บอกว่าอ่านง่ายและเข้าใจคือ ทีม
code ที่เขียนทั้งทีมมีรูปแบบเดียวกันหรือไม่ ?

เนื่องจากส่วนใหญ่นักพัฒนา
มักใช้เวลาในการอ่าน code
มักใช้เวลาในการทำความเข้าใจการทำงานของ code
มากกว่าการลงมือเขียนหรือแก้ไข code
ทำไมนะ ?

เคยไหมที่เปิด code ในแต่ละเครื่อง
แล้วทำไม code แสดงผลต่างกัน
ทั้ง space และ tab !!

เคยไหมต้องทำการ merge code ที่มี conflict หรือข้อขัดแย้ง
แถมเจอ code ที่หลายหลายรูปแบบ
มันยากต่อการ merge code มาก ๆ

เคยไหมต้องไปต่อ หรือ แก้ไข code ของคนอื่น
หรือแม้แต่ code ที่เขียนขึ้นมาเอง
ต้องเสียเวลาเรียนรู้
ต้องเสียเวลาจัดโครงสร้าง code
ดังนั้นเราไม่สามารถบอกได้เลยว่า
ต้องใช้เวลาในการแก้ไขหรือเพิ่ม code เท่าไร !!

เคยไหมต้องไปค้นหาข้อผิดพลาดใน code
ต้องมานั่ง debug
เพราะว่าอ่าน code ไม่รู้เรื่องเลย
หรือ code มันซับซ้อนเกินไป !!

เคยไหมที่ code ถูกจัดเรียงแบบกระโดดไปมาจนน่าปวดหัว
ขอ code แบบอ่านจากบนลงล่าง
และซ้ายไปขวาได้ไหม ?

สิ่งต่าง ๆ เหล่านี้คือ ปัญหาที่เจอกันได้บ่อย ๆ
ในการพัฒนา software !!
ดังนั้นเราน่าจะทำให้ชีวิตดีขึ้นกว่านี้กันบ้างนะ

เริ่มด้วยเรื่องแรก ตกลงการใช้งาน whitespace กันทั้งทีมซะ

ตัวอย่างเช่นการใช้งาน Tab vs Space
ถ้าใช้ space ทั้งหมดแล้ว
ตกลงกันเลยว่า Tab ต้องใช้กี่ space
ตกลงกันเลยว่า space ที่ใช้ตอนประกาศตัวแปร method for loop
และอื่น ๆ อีกมากมาย
เพื่อทำให้ code มีโครงสร้างที่เหมือนกัน
จากนั้นก็นำ lint มาใช้งานกันซะ

ลำดับการจัดเรียงของ member ต่าง ๆ ใน class หรือในไฟล์

ถ้ามีการกำหนดลำดับ
ถ้ามีการกำหนดกลุ่มของ code
ในแต่ละ class หรือแต่ละไฟล์ให้ชัดเจน
มันน่าจะช่วยให้ง่ายต่อการ merge code นะ
เช่น
ค่าคงที่อยู่บนสุด
รองลงมาคือ field ต่าง ๆ
รองลงมาคือ constructor
รองลงมาคือ public method
รองลงมาคือ private method

รูปแบบการตั้งชื่อก็สำคัญมาก ๆ

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

ให้เริ่มด้วยรูปแบบของการตั้งชื่อ เช่น
ตัวพิมพ์ใหญ่ทั้งหมดสำหรับค่าคงที่
การตั้งชื่อตัวแปรให้ใส่ prefix หรือ suffix เป็นต้น

แนะนำให้มีการ review code บ่อย ๆ
หรือให้มี pair programming กันตลอด

วิธีการตรวจสอบว่าตั้งชื่อดีหรือไม่
แนะนำให้ลองค้นหาดูนะ
ว่าคุณนึกชื่อนั้น ๆ ออกหรือไม่ ?

โครงสร้างของ package หรือ namspace แนะนำให้แบ่งตาม feature

จะได้หา code กันง่าย ๆ
ไม่ต้องพึ่งความสามารถของ Editor/IDE มากนัก

สุดท้ายอย่าลืมเขียน test นะครับ

มันจะช่วยทำให้เรากล้าแก้ไข code กัน
และใช้งาน Version Control ด้วยนะ

Reference Websites
https://dzone.com/articles/keep-your-code-consistent