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

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

Photo by David Clode on Unsplash

สวัสดีครับทุกคนนนน กลับมาอีกครั้งคงยังไม่เบื่อเจ้าหน้าปกตั๊กแตนเขียวของผมกันนะครับ 😁ในตอนแรกผมกะจะเกริ่นยาวๆหน่อย แต่ก็กลัวทุกคนเสียเวลา เพราะว่า Part นี้ก็ถือว่าเป็นอีกหนึ่ง Part หลักและเป็น Part สุดท้ายสำหรับหลักการสำคัญทั้ง 4 ของหนังสือ Naming Things ครับ!!

ก่อนอื่น ผมขอปรบมือและขอบคุณทุกคน สำหรับคนที่ตามมาตั้งแต่แรกหรืออ่านมาเรื่อยๆ รวมถึงคนที่พึ่งเข้ามาอ่านด้วยครับ!! คุณสุดยอดมาก👏👏👏👏 (หลงมาได้ไง หยอกๆ)

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

งั้นมาครับ จะได้ไม่เสียเวลา เรามาลุยกันต่อกับ หลักการสำคัญข้อสุดท้าย นั่นคือเรื่อง Distinguishability หรือ ความสามารถในการแยกแยะได้ นั้นเอง แต่ก่อนอื่นมาทบทวนกันอีกสักรอบก่อนครับ ว่าหลักการสำคัญทั้ง 4 ของหนังสือ Naming Things นั้นมีอะไรบ้าง

List of principle

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

สำหรับใครอยากทบทวน สามารถกลับไปอ่านเติมสาระได้อีกรอบตามลิงก์ด้านล่างได้เลยนะครับ

• Part 1 — Introduction
• Part 2 — Why is naming hard?
• Part 3 — List of Principles: 1. Understandability
• Part 4 — List of Principles: 2. Conciseness
• Part 5 — List of Principles: 3. Consistency

Distinguishability

A name should be visually and phonetically distinguishable from other names.
ชื่อควรจะมีรูปแบบในการมองเห็นและการออกเสียงที่แตกต่างกัน เพื่อที่จะให้แยกจากชื่ออื่นๆได้ชัดเจน

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

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

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

ปล. จากใจจริง ผมอ่านคำว่า Distinguishability ทีไรลิ้นพันกันทุกทีครับ 😂

Rules

กฎของ Distinguishability หรือ ความสามารถในการแยกแยะได้นั้น ก็จะมีหลักๆอยู่ 4 ข้อ ครับ หลายๆข้อด้านล่างก็มีคำศัพท์ที่ผมเองก็ไม่ค่อยคุ้นเท่าไหร่เหมือนกัน แต่จะพยายามเล่าให้เข้าใจง่ายที่สุดนะครับ มาดูกันในแต่ละข้อเลย

1. Avoid homographs and near-homographs

ก่อนอื่น ในกฎข้อที่ 1 นั้น เรามาเข้าใจคำว่า Homographs กันก่อน ในภาษาไทย Homographs มาจากคำว่า คำพ้องรูป ซึ่งคำพ้องรูปคือคำที่สะกดเหมือนกันแต่มีความหมายต่างกัน เดี๋ยวมาดูตัวอย่างกันก่อนครับ เราน่าจะเห็นภาพและเข้าใจได้ง่ายมากขึ้น หนังสือได้ยกตัวอย่างคำว่า “check” ซึ่งในภาษาอังกฤษเนี่ย คำนี้อาจหมายถึงการตรวจสอบหรือเช็คธนาคารก็ได้ การใช้คำพ้องรูปในการตั้งชื่อนั้น จึงจำเป็นที่จะใช้งานอย่างรอบคอบและระมัดระวังเพื่อหลีกเลี่ยงความสับสนของทั้งเราและทีม ด้วยครับ ตัวอย่างเช่น

# Bad
invoice.check() # อันนี้ check อะไรนะ "ตรวจสอบ" หรือ "เช็คธนาคาร" กันแน่

# Good
invoice.validate()
invoice.written_check()

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

# Bad - ผมว่าเคสนี้หลายคนเคยโดนพวก Autocomplete Hint เล่นงาน
class OrganizationOnboardingProcess:
class OrganizationOnboardingProcessor:

# Good
class Onboarding:
class OnboardingProcessor:

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

อีกตัวอย่างสำหรับเรื่องของ Near-Homographs ที่เราไม่ควรใช้ก็จะเป็นพวก การใช้ตัวพิมพ์ใหญ่-เล็กในชื่อที่ชัดเจนไม่มากพอ หรือการตั้งชื่อที่มีตัวอักษรที่ต่างกันเพียง 1–2 ตัวอักษร พวก “0” หรือ “O” (ศูนย์ หรือ โอ) ก็ควรระวัง รวมทั้งการตั้งชื่อโดยใช้ตัวอักษรเดี่ยวๆ ซึ่งนอกจากจะค้นหายากแล้ว (อย่างเช่นตัว a เราอาจจะเจอ “a” อีกหลายตัวตอนค้นหา) ยังสื่อความหมายได้ลำบากขึ้นอีกด้วย

# Bad
class Datastore:
class DataStore: #แทบแยกไม่ออกในแว๊บแรก ต้องเพ่งหน่อย

index_0 = 0
index_O = origin_point.index

# Good
class SqlDatabase:
class InMemoryDatabase:

initial_index = 0
origin_index = origin_point.index

สำหรับกฎข้อนี้ ถ้าใครสนใจเรื่องของ Near-Homographs อาจไปค้นหาเพิ่มเติมจาก Visually similar characters ต่อก็ได้ครับ เราจะเห็นว่ามีตัวอักษรอีกหลายตัวเลย ที่มีรูปลักษณะที่คล้ายคลึงกันครับ

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

2. Avoid homophones and near-homophones

กฎข้อต่อมาชื่อจะคล้ายกับข้อด้านบน แต่ Homophones จะเป็นคำพ้องเสียง คือคำที่เราอ่านแล้วออกเสียงเหมือนกัน แต่สะกดต่างกัน เช่น “whole” กับ “hole” ในภาษาอังกฤษ ซึ่งคำพวกนี้มักจะสร้างความสับสนในการสื่อสารแบบพูดคุย เช่นตอนที่เราคุยกับทีม ประชุม หรือตอนที่กำลังนำเสนองานต่างๆ

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

ส่วนอีกปัญหาสำหรับกฎข้อนี้นั้นก็คือ Near-Homophones หรือคำที่ออกเสียงคล้ายกัน ตอนที่เราตั้งชื่อตัวแปรหรือฟังก์ชั่นเราก็ควรหลีกเลี่ยงคำพวกนี้เช่นกัน ซึ่งวิธีแก้ไขเราควรหาคำที่มีความหมายเฉพาะและแยกแยะได้ง่ายจะดีกว่าครับ

# Bad
winnowed_results = winnow_results(results)
return window_results(winnowed_results)

# Good
valid_results = select_valid_results(results)
return window_results(valid_results)

สำหรับกฎข้อนี้นั้น ชื่อที่ดีก็ควรจะหลีกเลี่ยงคำพ้องเสียงและคำที่ออกเสียงคล้ายๆกันครับ

3. Avoid polysemes

กฎข้อต่อไปนั่นคือ การตั้งชื่อควรหลีกเลี่ยงคำที่มีหลายความหมาย หรือที่เราเรียกคำเหล่านั้นว่า Polyseme ผมอยากลองให้ย้อนกลับมาที่ในภาษาไทยก่อน เพื่อให้นึกภาพได้ชัดขึ้น เช่นคำว่า “หนังสือ” ซึ่งหนังสือในที่นี้อาจหมายถึง ผลงานวรรณกรรม, การ์ตูน, นิตยสาร หรือเล่มหนังสือจริงๆ หรือแบบดิจิตอล?

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

# Bad
book = Book.find_by_isbn(isbn)
book.books_in_stock_count

# Good
book = Book.find_by_isbn(isbn)
book.physical_copies_in_stock_count

จากตัวอย่างด้านบน เราจะพบว่าถ้าเราลงรายละเอียดลงไปจะช่วยให้เราเห็นและเข้าใจการทำงานรวมถึงผลลัพธ์ที่เราต้องการมากขึ้น เช่นในตัวอย่างที่ไม่ดีจะเห็นว่า เราเริ่มค้นหาจากรหัสที่เป็น ISBN ก็จริง แต่พอตอนเรานับจำนวน (count) เรากลับต้องมานึกอีกรอบว่า รหัส ISBN ที่เราหาและต้องการนับนั้น มันคือหนังสืออะไร?

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

4. Avoid names with distinct technical and non-technical meanings

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

อย่างตัวอย่างเช่น คำว่า “class” ในภาษาอังกฤษ ความหมายในตอนที่เราเขียนโปรแกรมอาจมี 2 แบบครับ

• ความหมายเชิงเทคนิค: เทมเพลต, แม่แบบสำหรับการสร้าง object
• ความหมายทั่วไป: ชั้นเรียน, กลุ่มนักเรียน, คลาสเรียน

# Bad
class Class:

# Good
class Course:

ซึ่งในกฎข้อนี้ เราก็ควรจะหลีกเลี่ยงการใช้คำที่มีความหมายซ้ำซ้อนกันถ้าเป็นไปได้ หรือถ้าเราจำเป็นต้องใช้จริงๆ เราควรเลือกใช้คำที่มีความหมายในโดเมนของโปรเจคหรือธุรกิจที่เรากำลังทำแทนการใช้ความหมายทางเทคนิค รวมทั้งยังมีคำที่เราต้องระวังอย่างเช่นคำว่า “event”, “message”, “window” หรือ “transaction”

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

Conclusion

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

1. หลีกเลี่ยงคำพ้องรูปและคำที่มีรูปแบบใกล้เคียงกัน
2. หลีกเลี่ยงคำพ้องเสียงและคำที่ออกเสียงคล้ายๆกัน
3. หลีกเลี่ยงคำที่มีหลายความหมาย
4. หลีกเลี่ยงชื่อที่มีความหมายทางเทคนิคและไม่ใช่ทางเทคนิคที่มีความหมายแตกต่างกัน

จบกันจนได้ครับ สำหรับหลักการหลักๆทั้ง 4 หลักการของหนังสือ Naming Things … เย้ วู้ววว (แต่เดี๋ยวก่อน) มันยังไม่จบจริงๆครับ คือหลักการหนะจบไปแล้ว แต่ยังมีเนื้อหาสำคัญๆที่น่าเอามาเล่าให้ฟังอีกเหมือนกันครับ ยกตัวอย่างเช่น

• Tradeoffs — มันดีไม่ดียังไงบ้าง เวลาเราเอาหลักการแต่ละอันมาใช้ มันมีอันไหนที่ตีกันบ้างไหม?
• Identifier Types —เราจะตั้งชื่อ พวก Class, Variable, Methods และ บลาๆ ยังไงให้ดี?
• Style Guides — Style Guides ที่ดีมันควรเป็นยังไง ประมาณไหน ถ้าเราเอามาใช้กับเราเองและทีม?

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

สำหรับ สรุปหนังสือ Naming Things: The Hardest Problem In Software Engineering ผมอาจจะต้องขอพักไว้ก่อนเพียงเท่านี้ครับ ยอมรับว่าอยากกลับไปชดใช้บาปหลายๆ Blog ที่ค้างไว้ใน Drafts ครับ หลายบาปเลยทีเดียวในนั้น ยังไงผมก็ขอขอบคุณทุกคนอีกครั้งนะครับ ที่ตามอ่านกันมาจนจบหลักการสุดท้าย

แต่ก่อนจะจากกันไป ชอบกดไลท์ ใช่กดรีพอร์ทเหมือนเดิมครับ 55+
ขอบคุณทุกคนที่อ่านมาจนจบครับ

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