ทะเลก็มีชื่อเป็นของตัวเองนะ: ศาสตร์แห่งการตั้งชื่อโค้ด

ลองนึกภาพว่าคุณกำลังยืนมองแผนที่โลกอยู่บนผนังห้องนอน สิ่งที่คุณเห็นคือแผ่นดินสีเขียวและผืนน้ำสีฟ้าขนาดมหึมาที่ล้อมรอบทวีปต่างๆ ถ้าเราถามว่าน้ำเหล่านั้นคืออะไร คำตอบง่ายๆ ก็คือ 'ทะเล' หรือ 'มหาสมุทร' แต่เราไม่เคยเรียกมันแค่นั้นใช่ไหมครับ?

เราเรียกมันว่า มหาสมุทรแปซิฟิก มหาสมุทรแอตแลนติก ทะเลอันดามัน หรืออ่าวไทย ทำไมเราถึงต้องมานั่งตั้งชื่อให้กับสิ่งที่ตัวมันเองก็คือน้ำเค็มเหมือนกันทั้งนั้น? คำตอบคือ ชื่อเหล่านั้นให้ขอบเขต ให้อัตลักษณ์ และให้ความหมาย มันบอกเราว่าน้ำแห่งนี้อยู่ตรงไหน มีพฤติกรรมอย่างไร และสำคัญที่สุดคือมันทำให้เราสื่อสารกันได้โดยไม่สับสน

ในโลกของการเขียนโปรแกรมก็เช่นเดียวกัน โค้ดทุกบรรทัดที่คุณพิมพ์ลงไป คือผืนน้ำที่กว้างใหญ่ และการตั้งชื่อตัวแปร ฟังก์ชัน หรือคลาส (Naming Conventions) ก็คือการตั้งชื่อให้กับทะเลเหล่านั้นนั่นเอง

น้ำคือน้ำ แต่ทะเลต้องมีชื่อ

หลายคนที่เริ่มหัดเขียนโปรแกรมมักจะมีความคิดว่า 'ขอให้โค้ดรันได้ก็พอแล้ว' ตัวแปรก็ตั้งชื่อ a, b, c, data1, data2 หรือไม่ก็ temp วางกันไป ซึ่งในตอนที่เขียน คุณอาจจะเข้าใจดีว่า temp คืออะไร แต่ลองกลับมาอ่านอีกครั้งในอีกสองสัปดาห์ คุณจะรู้สึกเหมือนกำลังล่องเรือกลางมหาสมุทรโดยไม่มีเข็มทิศ

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

ทำไมโปรแกรมเมอร์ถึงต้องเรียนรู้ Naming Conventions?

มีคำพูดที่คลาสสิกในวงการพัฒนาซอฟต์แวร์ว่า "Code is read much more often than it is written" (โค้ดถูกอ่านบ่อยกว่าที่ถูกเขียนขึ้นมาก) สิ่งนี้คือเหตุผลหลักที่ทำให้การตั้งชื่อเป็นทักษะที่สำคัญที่สุดอย่างหนึ่งของนักพัฒนา

ลดความซับซ้อนทางความคิด: ชื่อที่ดีบอกเจตนาได้ทันที คุณไม่ต้องเสียเวลาไล่อ่านลอจิกด้านในฟังก์ชันเพื่อทำความเข้าใจว่ามันทำอะไร
ทำงานร่วมกันได้ง่าย: ในทีมพัฒนา โค้ดของคุณจะถูกอ่านโดยเพื่อนร่วมทีม ชื่อที่ตั้งตามมาตรฐานทำให้ทุกคนพูดภาษาเดียวกัน
ลด Bug: การตั้งชื่อผิดหรือสับสน เช่น ตั้งชื่อตัวแปรว่า isUserActive แต่ค่าที่เก็บกลับเป็น String ของสถานะ อาจทำให้เกิด Bug ที่หาสาเหตุได้ยาก

รู้จักกับมหาสมุทรในโลกแห่งโค้ด (Naming Styles)

ในโลกของการเขียนโปรแกรม เราไม่ได้ตั้งชื่อกันตามอำเภอใจ แต่มีรูปแบบมาตรฐาน (Naming Styles) ที่ช่วยให้เราแยกแยะได้ว่าสิ่งนี้คืออะไร เหมือนการที่เราแยกระหว่าง 'อ่าว' 'ทะเล' และ 'มหาสมุทร'

1. CamelCase (อูฐ)

เป็นการตั้งชื่อที่ตัวอักษรแรกของคำแรกเป็นตัวพิมพ์เล็ก และคำต่อไปขึ้นต้นด้วยตัวพิมพ์ใหญ่ คล้ายกับโหนกอูฐ มักใช้กับตัวแปรและฟังก์ชัน

let userName = "John Doe";
function calculateTotalPrice() {
  // ...
}

2. PascalCase (อูฐตัวใหญ่)

คล้ายกับ CamelCase แต่ตัวอักษรแรกของคำแรกก็เป็นตัวพิมพ์ใหญ่ด้วย มักใช้กับ Class หรือ Component

class UserProfile {
  constructor(name) {
    this.name = name;
  }
}

3. snake_case (งู)

ใช้เครื่องหมายขีดล่าง _ คั่นระหว่างคำ ตัวอักษรทั้งหมดเป็นพิมพ์เล็ก เป็นที่นิยมมากในภาษา Python และ Ruby

def get_user_profile(user_id):
    return database.query(user_id)

4. kebab-case (ไม้เสียบลูกชิ้น)

ใช้ขีดกลาง - คั่นระหว่างคำ มักใช้ในการตั้งชื่อไฟล์, URL หรือ CSS Class เพราะภาษาบางตัวไม่อนุญาตให้ใช้ขีดกลางในตัวแปร

.btn-primary {
  background-color: blue;
}

5. SCREAMING_SNAKE_CASE (งูตะโกน)

เป็น snake_case แต่ใช้ตัวพิมพ์ใหญ่ทั้งหมด มักใช้สำหรับค่าคงที่ (Constants) ที่ไม่มีวันเปลี่ยนแปลง

const MAX_CONNECTION_LIMIT = 100;
const API_BASE_URL = "https://api.example.com";

กรณีศึกษา: ความหายนะของ 'ทะเลไม่มีชื่อ'

ผมเคยได้รับโจทย์ให้เข้าไปแก้ระบบ Inventory ของบริษัทหนึ่งที่พัฒนาต่อจากโปรแกรมเมอร์คนเก่าที่ลาออกไปแล้ว เมื่อเปิดไฟล์ดู สิ่งที่เจอคือความวิบัติของการตั้งชื่อ

function doStuff(x, y, flag) {
  let a = x * 2;
  if (flag) {
    return a + y;
  } else {
    return a - y;
  }
}

ฟังก์ชันนี้ชื่อ doStuff รับพารามิเตอร์มา 3 ตัวคือ x, y และ flag ตอนแรกผมนึกว่ามันคือการคำนวณราคาสินค้า แต่พอไล่เข้าไปในลอจิกลึกๆ พบว่ามันคือการคำนวณภาษีมูลค่าเพิ่ม สิ่งที่น่าจะตั้งชื่อว่า calculateVAT(price, taxRate, isIncluded) กลับกลายเป็น doStuff(x, y, flag)

ผลกระทบคือ งานที่น่าจะใช้เวลาแก้แค่ 10 นาที กลับกลายเป็นการนั่งไล่อ่านโค้ดทั้งระบบเพื่อทำความเข้าใจว่า x และ y มาจากไหน เสียเวลาไปกับมันเกือบ 2 วันเต็ม นี่คือเหตุผลว่าทำไมการตั้งชื่อถึงส่งผลต่อ Productivity ของทีมพัฒนาอย่างมหาศาล

3 หลักการตั้งชื่อเหมือนนักสำรวจมหาสมุทร

ถ้าจะให้ตั้งชื่อในโค้ดให้ดี จำ 3 หลักการนี้ไว้

1. ตั้งชื่อให้จำเพาะเจาะจง (Be Specific)

อย่าตั้งชื่อแค่ว่า data หรือ info มันกว้างเกินไป ถ้ามันคือข้อมูลผู้ใช้ ก็ตั้งชื่อว่า userData ถ้าเป็นข้อมูลสินค้า ก็ productInfo อย่าเรียกทะเลว่าน้ำ ให้เรียกมันว่าทะเลจีนใต้

2. หลีกเลี่ยงการใช้ตัวย่อ (Avoid Abbreviations) ยกเว้นเป็นที่นิยม

การตั้งชื่อ usrAddr อาจจะดูสั้นและเท่ แต่เมื่อเวลาผ่านไป คุณอาจจะนั่งคิดว่ามันคือ User Address หรือ User Administrator ใช้ userAddress จะชัดเจนกว่าและอ่านง่ายกว่า ยกเว้นตัวย่อที่เป็นมาตรฐานสากล เช่น URL หรือ API

3. ความสม่ำเสมอคือกุญแจ (Consistency)

ถ้าในโปรเจกต์คุณใช้ getUserData() ก็ให้ใช้คำว่า get กับฟังก์ชันดึงข้อมูลอื่นๆ ด้วย อย่าให้มี fetchUser(), retrieveUser(), pullUser() ปนกันไปหมด มันจะสร้างความสับสนให้คนที่เรียกใช้ฟังก์ชัน

สรุป: ตั้งชื่อให้คนรุ่นหลังเดินทางต่อได้

การเขียนโค้ดไม่ใช่แค่การสั่งคอมพิวเตอร์ให้ทำงาน แต่มันคือการสร้างแผนที่ให้กับนักพัฒนารุ่นต่อไป (ซึ่งอาจจะเป็นตัวคุณเองในอนาคต) ได้เดินทางต่อไปได้อย่างราบรื่น ทะเลก็มีชื่อเป็นของตัวเองนะ ตัวแปรและฟังก์ชันในโค้ดของคุณก็สมควรได้รับการปฏิบัติเช่นเดียวกัน

ลองกลับไปดูโค้ดที่คุณเขียนเมื่อวานนี้ มี 'ทะเลไม่มีชื่อ' ซ่อนอยู่ในนั้นไหม? ถ้ามี ลองเปลี่ยนมันซะ แล้วคุณจะรู้ว่าการ Refactor แค่เรื่องชื่อ สามารถทำให้โค้ดของคุณสวยงามและอ่านง่ายขึ้นขนาดไหน

คุณล่ะครับ เคยเจอชื่อตัวแปรในโค้ดที่ทำให้คุณอยากกรีดร้องที่สุดคืออะไร? มาแชร์กันในคอมเมนต์ได้เลย!