Coding standard การตั้งชื่อ

ในทางของการเขียนโปรแกรมคอมพิวเตอร์ “naming convention” คือชุดของกฎที่ถูกเลือกใช้ในการระบุซึ่ง การแสดงถึงตัวแปร ชนิดของฟังก์ชั่น และสิ่งอื่นๆ ภายในซอร์สโค้ดและเอกสารประกอบ เหตุผลในการใช้ naming convention มีดังต่อไปนี้

• เพื่อลดความพยายามในการอ่านและทำความเข้าใจซอร์สโค้ด

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

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

• ใช้คำให้เหมือนกัน (Consistency)

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

จากตัวอย่างทั้ง 3 มีจุดประสงค์ในการทำงานเดียวกันคือ “ดึงข้อมูลของผู้ใช้งาน” แต่ทั้ง 3 ใช้คำที่แตกต่างกัน ผลที่ตามมาของการใช้ที่หลากหลายในโปรเจค จะทำให้เกิดความคิดที่ขัดแย้งกัน ว่าเราควรจะเลือกคำใดในการตั้งชื่อตัวแปรหรือฟังก์ชั่้น ในอนาคตที่มีจุดประสงค์ในการทำงานแบบเดียวกัน เช่น “ดึงข้อมูลของสินค้า” จะเกิดความคิดที่ว่า ควรใช้ get, fetch หรือ retrive อันไหนดี ฉะนั้นการเลือกใช้คำให้เหมือนกันจะช่วยลดเวลาการตัดสินใจในสิ่งที่ไม่จำเป็นนั้นเอง

ใช้คำที่มีความหมายและอ่านออกเสียงได้อย่างชัดเจน (Use Pronounceable Names)

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

จากตัวอย่างคือ ตัวแปร fName ใช้เก็บข้อมูล “ชื่อ-นามสกุล” หรือ “ชื่อจริง” ก็ได้ เพราะ fName สามารถเป็นได้ทั้ง FirstName และ FullName แล้วแต่การตีความของตัวบุคคล เช่นเดียวกันกับ ตัวแปร tBook อาจจะถูกตีความว่า ใช้เก็บข้อมูล “จำนวนหนังสือ” หรือ “ชื่อของหนังสือ” เพราะ tBook อาจหมายถึง titleBook หรือ totalBook ก็ได้ ฉะนั้นการตั้งชื่อที่มีความหมายและอ่านออกเสียงได้อย่างชัดเจน จะช่วยลดปัญหาการนำตัวแปรไปใช้ผิดวัตถุประสงค์ของการทำงาน

ความแตกต่างที่มีความหมาย (Meaningful Distinctions)

บางครั้งคำๆ เดียวกันแต่จุดประสงค์ของการทำงานนั้นต่างกัน มีหลายครั้งที่คำๆ เดียวกันในบริบท (Context) ที่ต่างกัน ให้ผลลัพธ์ของการทำงานที่ไม่เหมือนกัน

ทั้งสอง class มีฟังก์ชั่นชื่อว่า add เหมือนกัน ทั้ง 2 ฟังก์ชั่นมีชื่อถูกต้องตรงตามวัตถุประสงค์ของ class ทั้งคู่ ใน class calculator ฟังก์ชั่น add(x,y) เป็นการบวกเลข 2 จำนวน ส่วนใน class cart ฟังชั่น add(x) เป็นการเพิ่มสินค้าลงในตระกร้า หากเราทำการ search ใน project ด้วย wording “add” เราจะพบ function ทั้งสอง จะดีกว่าไหม ถ้าเราเปลี่ยนเป็นแบบนี้
add(x,y) -> addNumbers(x, y)

add(x) -> insertElement(x)

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

ใช้คำที่มีความหมายในเชิงบวก (Be Positive)

ทิศทางความหมายของคำ ส่งผลต่อเวลาที่ใช้ในการตีความหมายและความเข้าใจต่อคำนั้นๆ โดยปกติแล้วของมนุษย์เราจะเข้าใจคำที่มีความหมายในเชิงบวกง่ายกว่าเชิงลบ และพื้นฐานการทำงานของ computer จะทำงานตามความ”จริง” (Boolean) เงื่อนไขนั้นจะต้องเป็น “จริง” เสมอ โปรแกรมจึงจะทำงานต่อไป

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

• If (notEnabled) {} หมายความว่า ถ้า”ไม่ได้เปิดใช้งาน” จึงจะทำงานตามซอร์สโค้ดภายใต้ {} (Curly brackets)

• If (notClosed) {} หมายความว่า ถ้า”ไม่ปิด” จึงจะทำงานตามซอร์สโค้ดภายใต้ {} (Curly brackets)

• If (notBanned) {} หมายความว่า ถ้า”ไม่ห้าม” จึงจะทำงานตามซอร์สโค้ดภายใต้ {} (Curly brackets)

ถ้าเราเปลี่ยนเงื่อนไขให้เป็นความหมายในเชิงบวกดังนี้

• If (isDisabled) {} หมายความว่า ถ้า”ถูกปิดใช้งาน” จึงจะทำงานตามซอร์สโค้ดภายใต้ {} (Curly brackets)

• If (isOpen) {} หมายความว่า ถ้า”เปิด” จึงจะทำงานตามซอร์สโค้ดภายใต้ {} (Curly brackets)

• If (isAllowed) {} หมายความว่า ถ้า”ได้รับอนุญาต” จึงจะทำงานตามซอร์สโค้ดภายใต้ {} (Curly brackets)

จะเห็นได้ว่าซอร์สโค้ดที่มีเงื่อนไขในเชิงบวก ใช้เวลาในการอ่านและทำความเข้าใจน้อยกว่า อีกทั้งยังไม่สร้างความสับสนในเงื่อนไขอีกด้วย

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

แหล่งอ้างอิง

• Naming Convention - 9 Basic Rules for any Piece of Code

• Naming convention (programming) - Wikipedia