Quantcast
Channel: cc :: somkiat
Viewing all articles
Browse latest Browse all 1997

ว่าด้วยเรื่องของ source code

$
0
0

เรื่องที่ถกเถียงกันประจำสำหรับการเขียน 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

Viewing all articles
Browse latest Browse all 1997

Trending Articles