สรุปหนังสือ Naming Things: The Hardest Problem In Software Engineering (Part 3— List of Principles: 1. Understandability)

หมายเหตุการย้ายบทความ: บทความนี้เผยแพร่ครั้งแรกเมื่อ 2024-10-26 บน Medium และย้ายมาเผยแพร่ในบล็อกนี้เมื่อ 2026-10-18 โดยคงเนื้อหาและบริบทเดิม ตัวอย่างโค้ดไม่ได้ผ่านการรันทดสอบใหม่

ภาพประกอบ

Photo by David Clode on Unsplash

สวัสดีครับทุกคน หลังจากที่ห่างหายไปสักพัก ขอกลับมาลุยต่อ Part 3 ของสรุปหนังสือ Naming Things กันต่อครับ ซึ่งในส่วนของ Part 3 นี้ เราจะเข้าไปสู่ตัว Principles ของมันละครับ หลักๆ ก็จะมีอยู่ประมาณ 4 ตัว แต่เราจะมาพูดถึงกันที่ตัวแรกก่อน นั่นคือ Understandability ผมขอเรียกมันว่า ความสามารถในการทำความเข้าใจ ละกันครับ (แต่พอเป็นการตั้งชื่อ จะบอกว่าเป็น ความง่ายต่อการทำความเข้าใจ จะตรงขึ้นไหมนะ 😝)

ในตัวของ Part นี้เองก็จะมีกฎย่อยๆของมัน รวมทั้งตัวอย่างคร่าวๆให้เห็นเป็นไอเดียในการนำไปใช้ครับ ส่วนถ้าใครที่ยังไม่ได้อ่านในส่วนของ part ก่อนๆ ก็สามารถตามย้อนกลับไปอ่านได้ตามลิงก์ด้านล่างนี้นะครับ

มาลุยกันเลยครับ

List of principle

Understandability: ชื่อที่ดีควรอธิบายสิ่งที่มันจะสื่อถึงได้ดี (ง่ายต่อการทำความเข้าใจ)
Conciseness: ชื่อที่ดีควรใช้แค่คำที่จำเป็นในการอธิบายตัวมันเอง
Consistency: ชื่อที่ดีควรมีความสม่ำเสมอของรูปแบบในการตั้งชื่อ
Distinguishability: ชื่อที่ดีควรแยกความแตกต่างจากชื่ออื่นๆได้ง่าย

จากลิสต์ด้านบน หนังสือเล่มนี้จะอธิบายหลักการหลักๆไว้ 4 ตัว ซึ่งใน blog นี้ เราจะมาเริ่มกันที่ตัว Understandability กันก่อน ว่าความหมายของการตั้งชื่อให้อ่านหรือสร้างความเข้าใจได้ง่ายมันเป็นยังไงบ้าง

Understandability

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

ช่วยให้คนอ่านเข้าใจได้ทันที ปรู๊ดปร๊าด ไม่ต้องคิดนานว่านี่คืออะไรนะ
จำง่าย… ไม่ต้องคอยนึก หรือ ถามซ้ำ
อ่านแล้วทำงานต่อได้เร็ว

ผมเลยขอสรุปสั้นๆก่อนว่าใน part ของ Understandability นั้นคือ ชื่อที่เข้าใจได้ง่ายจะช่วยให้คนอื่นเข้าใจได้เร็ว จำได้แม่น ทำงานได้สบายขึ้นเยอะ ไม่ต้องนั่งปวดหัวเดาความหมายกันให้เสียเวลาครับ

Rules

ในส่วนของ Understandability ก็จะมีกฎคร่าวๆอยู่ประมาณ 14 ข้อ ที่จะช่วยให้การตั้งชื่อของเรามีประสิทธิภาพและเข้าใจง่าย เดี๋ยวลองมาดูกันเป็นข้อๆครับ

1. Describe the concept

ถ้าอยากให้คนอ่านเข้าใจ ชื่อต้องบอกว่ามันคืออะไร ทำอะไรได้ ชัดๆตรงๆไปเลย อ่านปุ๊บ เข้าถึงคอนเซ็ปต์ได้ปั๊บ อย่างเช่นถ้ามันเป็นจักรยาน ก็ตั้งไปเลยว่า “จักรยาน” อย่าไปตั้งชื่ออื่นที่ไม่ค่อยเกี่ยวกัน ไม่ชัดเจนหรือทำให้คนอ่านต้องมาเดาอีกรอบครับ

# Bad
foo, thing, scooter

# Good
bicycle

2. Use dictionary terms

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

# Bad
o, org, people_group

# Good
organization

3. Use problem-domain terms

การตั้งชื่อควรใช้คำศัพท์จาก “โดเมนของปัญหา — problem-domain” ซึ่งหมายถึงคำที่เกี่ยวข้องกับปัญหาที่เราต้องแก้ เช่น ความต้องการและเป้าหมาย แทนที่จะใช้คำจาก “โดเมนของวิธีการหรือคำตอบ — solution-domain” ที่เกี่ยวกับวิธีการแก้ปัญหา เพราะ คำจาก problem-domain มักจะเข้าใจง่ายกว่าและมีความคงเส้นคงวามากกว่าครับ

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

# Bad
schedule_events(events)

# Good
schedule_meetings(meetings)

4. Use standard terms for domain-agnostic concepts

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

ตัวอย่างเช่น เมื่อเราลบข้อมูลในฐานข้อมูล ควรใช้คำว่า “delete” และ “row” แทนที่จะใช้คำที่ไม่เป็นมาตรฐานอย่าง “remove” หรือ “record” การเลือกใช้คำที่ถูกต้องจะทำให้โค้ดของเราชัดเจนและเข้าใจง่ายขึ้นครับ ยกตัวอย่างด้านล่าง

# Bad
Database.remove_record(table, primary_key)

# Good
Database.delete_row(table, primary_key)

หรืออย่างที่เราเคยเห็นว่า การใช้คำสั่งในระบบ Unix/Linux ควรใช้คำศัพท์มาตรฐานเพื่อความชัดเจน เช่น เมื่อส่งสัญญาณ kill ไปยัง process เราควรใช้คำว่า “kill” และ “PID” (Process ID) แทนที่จะใช้คำว่า “stop” หรือ “process number”

# Bad
Process.stop(process_id, signal_name)

# Good
Process.kill(pid, signal_name)

5. Use correct pluralization

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

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

# Bad
users = User.where(id=user_id)[0]

# Good
user = User.where(id=user_id)[0]

# -----------------------------

# Bad
user = User.where(state='valid')

# Good
users = User.where(state='valid')

# -----------------------------

# Bad
validate_user(users)

# Good
validate_users(users)

6. Use accurate parts of speech

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

ตัวอย่างเช่น ถ้าในคลาส User มี method ที่ทำหน้าที่ตรวจสอบความถูกต้องของข้อมูลผู้ใช้ ควรตั้งชื่อว่า “validate” แทนที่จะเป็น “validation” เพราะ “validate” เป็นคำกริยาที่สื่อถึงการกระทำ ในขณะที่ “validation” เป็นคำนามที่หมายถึงกระบวนการตรวจสอบ พอมาถึงตรงนี้แล้วจะเห็นได้ว่า การใช้คำกริยาจะทำให้เข้าใจได้ทันทีว่า method นี้ทำหน้าที่อะไร

# Bad
user.validation()

# Good
user.validate()

หรือในตัวอย่างอื่นๆ สำหรับ method ที่คืนค่าเป็น boolean (true or false) เช่น การตรวจสอบว่าผู้ใช้ถูกต้องหรือไม่ ควรใช้กริยาเชื่อม (linking verb) เช่น “is” ตามด้วยส่วนเติมเต็มประธาน (subject complement) เช่น “valid” หรือใช้คำคุณศัพท์ตามด้วยเครื่องหมายคำถาม เช่น “isValid” หรือ “valid?” การตั้งชื่อแบบนี้จะทำให้เข้าใจได้ทันทีว่า method นี้ตรวจสอบอะไรอยู่และคืนค่าเป็น boolean

# Bad
user.validate()

# Good
user.is_valid(), user.valid?()

ทั้งนี้ทั้งนั้น อย่าลืมด้วยนะครับ ว่าภาษานั้นๆที่เราเขียนมันจะมีพวก naming conventions หรือ style guide ยังไงบ้าง ซึ่งเราก็ควรจะทำให้สอดคล้องกับภาษานั้นๆด้วยครับ😄

7. Use accurate names for booleans

การตั้งชื่อตัวแปรหรือ method ที่เป็น boolean ควรสื่อถึง “ค่าจริง-true” หรือ “ค่าเท็จ-false” ได้อย่างชัดเจน ชื่อควรบ่งบอกคุณสมบัติที่มันเป็นตัวแทนอย่างตรงไปตรงมา เราควรจะหลีกเลี่ยงการใช้คำนามที่ boolean ตัวนั้นได้อธิบาย แต่ควรใช้คำคุณศัพท์ที่บรรยายคุณสมบัติที่ boolean นั้นแสดงออกมาจะดีกว่า

ยกตัวอย่างเช่น ถ้า method นั้นแสดงว่ากระบวนการอะไรสักอย่างเสร็จสมบูรณ์หรือไม่ ควรตั้งชื่อว่า “is_complete” หรือ “complete?” แทนที่จะเป็น “status” เพราะคำว่า “status” บ่งบอกว่ามีสถานะหลายแบบ ซึ่งอาจทำให้คนอ่านเข้าใจผิดว่าเป็นสตริงหรือ enum หรืออื่นๆ

# Bad เพราะเราไม่รู้ว่ามันคือ status อะไร คนอ่านต้องไปอ่านต่ออีกว่าข้างใน method ทำอะไรถึงจะรู้
if process.status():
  send_confirmation()

# Good
if process.is_complete():
  send_confirmation()

โดยทั่วไปแล้ว ชื่อสำหรับตัวแปรหรือ method ที่คืนค่า boolean ควรเป็นกริยาเชื่อมตามด้วยส่วนเติมเต็มประธาน (เช่น is_complete, has_admin_access) หรือเป็นคำคุณศัพท์ โดยเฉพาะอย่างยิ่งถ้าภาษานั้นสนับสนุนการใช้เครื่องหมายคำถามที่ท้ายชื่อเมธอด (เช่น complete?, accessible_to_admins?) วิธีนี้จะทำให้ความหมายของ boolean ชัดเจนและเข้าใจง่าย ช่วยให้โค้ดมีความหมายในตัวเองมากขึ้นครับ

8. Include units in measurements

การตั้งชื่อตัวแปรหรือฟังก์ชันที่เกี่ยวข้องกับการวัด เช่น ระยะทางหรือเวลา ควรรวมหน่วยวัดเข้าไปด้วยเสมอ เพราะการวัดส่วนใหญ่จะไม่มีความหมายเลย ถ้าเราไม่ได้ใส่หน่วยเข้าไป ถึงแม้ว่าบางครั้งเราอาจจะพอเดาหน่วยนั้นได้ก็ตาม การใส่หน่วยไว้ในชื่อจึงช่วยให้โค้ดชัดเจนและลดความสับสนได้ อย่างเช่น ควรใช้ “distance_meters” แทนที่จะเป็นแค่ “distance” ธรรมดาเพียวๆโล่งๆ

อย่างไรก็ตาม ก็มีบางกรณีที่การ “ไม่ใส่หน่วย” อาจเหมาะสม เช่น ถ้าในโค้ดมีการใช้การวัดเวลาบ่อยมากและใช้หน่วยวินาทีเสมอ หรือถ้าค่าเงินในโค้ดเป็นสกุลเงินเดียวตลอด (เช่น USD หรือ EUR) ในกรณีเหล่านี้ หน่วยอาจชัดเจนพอที่จะละเว้นได้ แต่ควรมีการตกลงกันในทีมและมีเอกสารอธิบายไว้อย่างชัดเจนสำหรับตัวโปรแกรมนั้นๆ เพื่อป้องกันความสับสนในอนาคต ซึ่งการตัดสินใจว่าจะรวมหรือละเว้นหน่วยควรคำนึงถึงความชัดเจนและความเข้าใจง่ายของโค้ดเป็นหลัก รวมถึงข้อตกลงในทีมด้วยครับ

# Bad
elapsed_duration

# Good
elapsed_duration_in_days

# -----------------------------

# Bad
remaining_distance

# Good
remaining_distance_in_meters

# -----------------------------

# Bad
temperature

# Good
temperature_in_celsius”

9. Avoid unconventional single-letter names

การใช้ชื่อตัวแปรที่เป็นตัวอักษรเดียวเป็นเรื่องค่อนข้างพบเห็นได้บ่อย โดยอาจคิดเป็น 10–20% ของชื่อตัวแปรทั้งหมด แต่การใช้งานมักแตกต่างกันไปตามแต่ละภาษา บางครั้งการใช้ตัวอักษรเดียวก็เป็นที่ยอมรับ เช่น การใช้ i และ j เป็นตัวนับใน loop ต่างๆ หรือ p และ q สำหรับ pointer แต่อย่างไรก็ตาม การใช้ชื่อที่ยาวขึ้นอาจให้ประโยชน์มากกว่าในหลายกรณี

ซึ่ง การใช้ชื่อตัวแปรที่เป็นตัวอักษรเดียวควรทำเมื่อมีข้อตกลงร่วมกันในภาษานั้นๆ และความหมายที่ชัดเจน ไม่งั้นเราก็ควรใช้ชื่อเต็มที่เป็นคำๆไปเลยจะดีกว่า เพราะมีงานวิจัยหลายชิ้นแสดงให้เห็นว่าการใช้ชื่อเต็มช่วยเพิ่มความเข้าใจและการจดจำได้ดีกว่า นอกจากนี้แล้ว การใช้ตัวอักษรเดียวบางตัวอาจทำให้เกิดความสับสน เช่น ตัว “l” (ตัวแอล) อาจถูกเข้าใจผิดว่าเป็นเลข “1” หรือตัว “o” (ตัวโอ) อาจถูกเข้าใจผิดว่าเป็นเลข “0” ได้ ลองดูจากตัวอย่างด้านล่าง จะเห็นได้ว่าตัวอักษรมันใกล้เคียงกันมาก อย่างเลขหนึ่งกับตัวแอล คือมันมองแว๊บแรกแทบไม่ต่างกัน😥

# Bad
u = users[0]

# Good
user = users[0]

# -----------------------------

# Bad
l = users.length
row_count = l + 1

# Good
user_count = users.length
row_count = user_count + 1

# -----------------------------

# Bad
for u in users:
  print(u.name)

# Good
for user in users:
  print(user.full_name)

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

10. Avoid abbreviations

การใช้คำย่อ ทั้งแบบตัดคำ หรือ ตัวย่อ เช่น “org” แทน “organization” และ “AP” แทน “accounts payable” มักจะทำให้เข้าใจได้ยากกว่าการใช้คำเต็ม เราเองจึงควรใช้คำย่อให้น้อยที่สุด แต่อย่างไรก็ตาม คำย่อที่เป็นที่รู้จักกันดี อย่างเช่น “URL”, “DNS”, และ “ID” ก็ยังสามารถใช้ได้ เพราะไม่ก่อให้เกิดปัญหาเช่นเดียวกับคำย่อที่ไม่เป็นที่รู้จัก การใช้คำย่อที่ไม่คุ้นเคยอาจทำให้ผู้อ่านเข้าใจผิดหรือสับสนและอาจทำให้ยากต่อการค้นหาในโค้ดของเรา

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

# Bad
ap, acts_payable

# Good
accounts_payable

# -----------------------------

# Bad
org

# Good
organization

11. Avoid non-standard symbolic names

บางภาษาโปรแกรมมิ่งอนุญาตให้ใช้ชื่อสัญลักษณ์ได้ เช่น ฟังก์ชันใน Scala หรือเมธอดใน Ruby อาจตั้งชื่อว่า “<<–>>” ได้ แม้ว่าสัญลักษณ์บางตัว เช่น “+”, “-”, “==”, “!=” จะเป็นที่เข้าใจกันดีในหมู่โปรแกรมเมอร์ แต่ก็มีสัญลักษณ์อีกมากมายที่ไม่เป็นที่รู้จักทั่วไป การใช้ชื่อสัญลักษณ์ที่ไม่เป็นสากลมักทำให้เข้าใจยาก จดจำยาก ค้นหาในโค้ดหรือออกเสียงก็ยาก แม้ว่าความสั้นกระชับของมันอาจดึงดูดโปรแกรมเมอร์บางคน แต่ข้อเสียในด้านความเข้าใจยากมักจะมีน้ำหนักมากกว่า

ตัวอย่างเช่น หากเรากำลังตั้งชื่อ method ใน Ruby ที่ใช้เรียกฟังก์ชันกับทุกองค์ประกอบในคอลเลกชันสักตัว ควรตั้งชื่อว่า “map” แทนที่จะใช้ชื่อที่เป็นสัญลักษณ์ การใช้ชื่อที่เป็นคำจริงๆ จะช่วยให้โค้ดอ่านง่ายขึ้น เข้าใจง่ายขึ้น และบำรุงรักษาได้ง่ายขึ้นในระยะยาว นอกจากนี้ ยังช่วยให้ผู้ที่ไม่คุ้นเคยกับโค้ดสามารถเข้าใจได้ง่ายขึ้นด้วย การหลีกเลี่ยงการใช้ชื่อสัญลักษณ์ที่ไม่เป็นมาตรฐานจึงเป็นแนวปฏิบัติที่ดีในการเขียนโค้ดที่มีคุณภาพและเป็นมืออาชีพ

# Bad
def ->(&block)

# Good
def map(&block)

12. Avoid cleverness

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

ตัวอย่างเช่น ถ้าเรากำลังเขียน method ที่ลบหัวข้อย่อยออกจากข้อความ เราอาจคิดจะใช้ชื่อล้ำๆ เช่น apply_kevlar(text) แทนที่จะใช้ชื่อตรงๆ อย่าง remove_bullets(text) การทำแบบนี้อาจทำให้คนอื่นที่มาอ่านโค้ดของเราต้องหยุดคิดเพื่อทำความเข้าใจความหมาย หรือในกรณีที่แย่ที่สุด พวกเขาอาจไม่เข้าใจความหมายเลย

การใช้ชื่อที่ล้ำเกินไปยังอาจลดความสม่ำเสมอของโค้ด เช่น ถ้ามีคนพยายามหา method ทั้งหมดที่ลบบางอย่างออกจากข้อความ พวกเขาอาจค้นหาคำว่า “remove” และจะไม่พบเมธอดที่ชื่อ apply_kevlar(text) นี่จะทำให้การทำงานร่วมกันและการบำรุงรักษาโค้ดยากขึ้น

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

# Bad
apply_kevlar(text)

# Good
remove_bullets(text)

13. Avoid usage of temporary or irrelevant concepts

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

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

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

# Bad
kill_em_all(processes)

# Good
kill_processes(processes)

14. Consider the audience’s familiarity with the name

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

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

Conclusion

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

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

ในเรื่องของ Understandability ก็จะมีประมาณนี้ครับ เพื่อนๆเองหลังจากอ่านจบและนำแต่ละข้อไปปรับปรุงใช้ในโค้ดตัวเองก็อย่าลืมเรื่อง style guide หรือ code conventions ของภาษานั้นๆที่เราเขียนด้วยนะครับ ตกลงกับตัวเอง ตกลงกับทีมให้ดี จะได้ไม่ตีกันครับ ฮ่าๆ 🤣ไว้เดี๋ยวมาเจอกันใน Principle ตัวต่อๆไปครับ

สุดท้ายนี้ ชอบกดไลท์ ใช่กดรีพอร์ท แฮ่
ขอบคุณทุกคนที่อ่านมาจนจบครับ

อยากให้ทุกคนสนุกกับการเขียนโค้ดครับ
Be Lazy & Happy Coding 🤤🖥🤗