อธิบายรูปแบบการตั้งชื่อและแบบแผน

รูปแบบที่พบบ่อย

camelCase บางครั้งเรียกว่า lower camel case และ PascalCase เรียกว่า upper camel case ส่วน CONSTANT_CASE เป็นที่รู้จักในชื่อ screaming snake case ด้วย

รูปแบบที่แต่ละภาษาและรูปแบบคาดหวัง

ระบบนิเวศส่วนใหญ่ตกลงแบบแผนกันมานานแล้ว และการทำตามช่วยให้คนที่คุ้นเคยกับระบบนิเวศนั้นอ่านโค้ดได้ง่ายขึ้น

ในภาษาโปรแกรมส่วนใหญ่ ใช้ kebab-case ตั้งชื่อตัวแปรไม่ได้ เพราะยัติภังค์ถูกอ่านเป็นเครื่องหมายลบ order-total หมายถึง order ลบ total

อักษรย่อและตัวเลข

อักษรย่อเป็นจุดที่แบบแผนต่างกันมากที่สุด แนวทางหนึ่งเขียนเป็นตัวพิมพ์ใหญ่ทั้งหมด (userID, parseHTML) อีกแนวทางถือเป็นคำธรรมดา (userId, parseHtml) คู่มือสไตล์ Java และ JavaScript ของ Google ใช้แนวทางที่สอง ซึ่งทำให้ขอบเขตของคำชัดเจนเมื่ออักษรย่อมาต่อกัน XmlHttpRequest แยกคำได้ง่ายกว่า XMLHTTPRequest แนวทาง .NET ของ Microsoft เขียนอักษรย่อสองตัวเป็นตัวพิมพ์ใหญ่ (IOStream) และใช้ตัวพิมพ์ใหญ่เฉพาะตัวแรกของอักษรย่อที่ยาวกว่า (HtmlButton) ส่วน API ของเบราว์เซอร์ XMLHttpRequest ผสมทั้งสองแบบ จึงมักถูกยกเป็นตัวอย่างที่ควรหลีกเลี่ยง

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

Title Case และ Sentence case ในหัวเรื่อง

ในหัวเรื่องภาษาอังกฤษ คู่มือสไตล์ไม่ได้ใช้ตัวพิมพ์ใหญ่กับทุกคำแบบเดียวกัน สไตล์ AP และ Chicago ให้คำนำหน้านาม คำเชื่อม และบุพบทสั้น ๆ เป็นตัวพิมพ์เล็ก ยกเว้นเมื่ออยู่ต้นหรือท้าย (“The Lord of the Rings”) และรายการที่แน่นอนต่างกันเล็กน้อย คู่มือส่วนติดต่อผู้ใช้และเอกสารจำนวนมาก รวมถึงคู่มือเอกสารสำหรับนักพัฒนาของ Microsoft และ Google ใช้ Sentence case (“Change your password”) ซึ่งใช้ให้สม่ำเสมอได้ง่ายกว่าและดูเป็นทางการน้อยกว่า

Title Case ของตัวแปลง LeedyBox ใช้ตัวพิมพ์ใหญ่กับทุกคำ เหมาะกับป้ายกำกับและชื่อที่คล้ายตัวแปร แต่ไม่เหมาะกับหัวเรื่องแบบหนังสือพิมพ์ ให้เปลี่ยนคำสั้น ๆ กลับเป็นตัวพิมพ์เล็กด้วยตนเองภายหลัง

การแปลงระหว่างรูปแบบทำให้ข้อมูลหายไป

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

ดังนั้นให้ถือรูปแบบหนึ่งเป็นหลัก หากฐานข้อมูลใช้ snake_case และโค้ดใช้ camelCase ให้แปลงที่รอยต่อทุกครั้งในทิศทางเดียวกัน แทนการเก็บชื่อไว้ทั้งสองแบบ

การเปลี่ยนชื่อคีย์ที่รอยต่อของ API

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

ระวังการชนกัน user_name และ userName กลายเป็นคีย์เดียวกันไม่ว่าในรูปแบบใด และคีย์หนึ่งจะเขียนทับอีกคีย์ สัญลักษณ์นำหน้าอย่าง _id หรือ $ref มักมีความหมายต่อฐานข้อมูลหรือสคีมา จึงควรตรวจว่าเปลี่ยนชื่อได้หรือไม่

ตัวพิมพ์ใหญ่และเล็กในภาษาอื่นนอกจากภาษาอังกฤษ

กฎของตัวพิมพ์ใหญ่และเล็กไม่เหมือนกันทุกภาษา ตัว ß ในภาษาเยอรมันกลายเป็น SS เมื่อเป็นตัวพิมพ์ใหญ่ คำจึงยาวขึ้น ภาษาตุรกีมี i แบบมีจุดและ ı แบบไม่มีจุด คู่ตัวพิมพ์ใหญ่คือ i → İ และ ı → I ขณะที่กฎเริ่มต้นของภาษาโปรแกรมส่วนใหญ่เปลี่ยน i เป็น I toUpperCase() ของ JavaScript ใช้กฎเริ่มต้น ส่วน toLocaleUpperCase('tr') ใช้กฎของภาษาตุรกี ภาษาเกาหลี จีน และญี่ปุ่นไม่มีตัวพิมพ์ใหญ่และเล็กเลย จึงเปลี่ยนเพียงตัวคั่นระหว่างคำ

ตัวพิมพ์ใหญ่และเล็กยังมีผลกับชื่อไฟล์ได้ด้วย Windows และ macOS ในค่าเริ่มต้นถือว่า Readme.md และ README.md เป็นไฟล์เดียวกัน ขณะที่ Linux ถือเป็นสองไฟล์ การเปลี่ยนชื่อที่เปลี่ยนแค่ตัวพิมพ์อาจไม่ถูกตรวจพบในระบบหนึ่ง และทำให้ลิงก์หรือการ import เสียในอีกระบบ

คำถามที่พบบ่อย