แบบแผนการตั้งชื่อ JSON [ปิด]

มีมาตรฐานในการตั้งชื่อ JSON หรือไม่ ฉันเห็นตัวอย่างส่วนใหญ่ที่ใช้ตัวพิมพ์เล็กทั้งหมดคั่นด้วยเครื่องหมายขีดล่าง (lower_case) แต่คุณสามารถใช้ PascalCase หรือ camelCase ได้หรือไม่?

ไม่มีมาตรฐานเดียว แต่ฉันได้เห็น 3 รูปแบบที่คุณพูดถึง ("Pascal / Microsoft", "Java" ( camelCase) และ "C" (ขีดล่าง, snake_case)) - รวมถึงอย่างน้อยหนึ่งอย่างkebab-caseเช่นlonger-name)

ดูเหมือนว่าส่วนใหญ่จะขึ้นอยู่กับผู้พัฒนาพื้นหลังของบริการที่มีปัญหา ผู้ที่มีพื้นหลัง c / c ++ (หรือภาษาที่ใช้การตั้งชื่อที่คล้ายกันซึ่งรวมถึงภาษาสคริปต์จำนวนมากทับทิม ฯลฯ ) มักจะเลือกตัวเลือกขีดล่าง; และพักผ่อนในทำนองเดียวกัน (Java vs .NET) ยกตัวอย่างเช่นห้องสมุด Jackson ที่ถูกกล่าวถึงให้ถือว่าการประชุมการตั้งชื่อ Java bean (camelCase )

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

ในเอกสารนี้คู่มือสไตล์ JSON ของ Google (คำแนะนำสำหรับการสร้าง JSON API ที่ Google)

แนะนำว่า:

1. ชื่อคุณสมบัติต้องเป็นสตริง camelCased , ASCII

2. อักขระตัวแรกจะต้องเป็นตัวอักษรเครื่องหมายขีดล่าง (_) หรือเครื่องหมายดอลลาร์ ($)

ตัวอย่าง:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

ทีมของฉันติดตามการประชุมนี้

หลักฐาน

นอกจากนี้ยังไม่มีการตั้งชื่อมาตรฐานของคีย์ใน JSON ตามส่วนวัตถุของข้อมูลจำเพาะ:

ไวยากรณ์ JSON ไม่ได้กำหนดข้อ จำกัด ใด ๆ กับสตริงที่ใช้เป็นชื่อ ...

ซึ่งหมายถึงcamelCaseหรือsnake_caseควรทำงานได้ดี

ปัจจัยขับเคลื่อน

การกำหนดระเบียบการตั้งชื่อ JSON ทำให้เกิดความสับสนมาก อย่างไรก็ตามสิ่งนี้สามารถหาได้ง่ายถ้าคุณแบ่งมันออกเป็นส่วนประกอบ

1. ภาษาการเขียนโปรแกรมสำหรับสร้าง JSON

   • Python - snake_case
   • PHP - snake_case
   • Java - camelCase
   • JavaScript - camelCase

2. JSON เองไม่มีการตั้งชื่อคีย์มาตรฐาน

3. ภาษาการเขียนโปรแกรมสำหรับการวิเคราะห์ JSON

   • Python - snake_case
   • PHP - snake_case
   • Java - camelCase
   • JavaScript - camelCase

จับคู่คอมโพเนนต์ให้ตรงกัน

1. Python » JSON » Python - snake_case - เป็นเอกฉันท์
2. Python » JSON » PHP - snake_case - เป็นเอกฉันท์
3. Python » JSON » Java - snake_case - โปรดดูปัญหา Javaด้านล่าง
4. Python » JSON » JavaScript - snake_caseจะเข้าท่า ขันสกรูปลายด้านหน้าออก
5. Python » JSON »คุณไม่รู้ - snake_caseจะเข้าท่า เกลียวตัวแยกวิเคราะห์
6. PHP » JSON » Python - snake_case - เป็นเอกฉันท์
7. PHP » JSON » PHP - snake_case - เป็นเอกฉันท์
8. PHP » JSON » Java - snake_case - โปรดดูปัญหา Javaด้านล่าง
9. PHP » JSON » JavaScript - snake_caseจะเข้าท่า ขันสกรูปลายด้านหน้าออก
10. PHP » JSON »คุณไม่รู้ - snake_caseจะเข้าท่า เกลียวตัวแยกวิเคราะห์
11. Java » JSON » Python - snake_case - โปรดดูปัญหา Javaด้านล่าง
12. Java » JSON » PHP - snake_case - โปรดดูปัญหา Javaด้านล่าง
13. Java » JSON » Java - camelCase - เป็นเอกฉันท์
14. Java » JSON » JavaScript - camelCase - เป็นเอกฉันท์
15. Java » JSON »คุณไม่รู้ - camelCaseจะเข้าท่า เกลียวตัวแยกวิเคราะห์
16. JavaScript » JSON » Python - snake_caseจะเข้าท่า ขันสกรูปลายด้านหน้าออก
17. JavaScript » JSON » PHP - snake_caseจะเข้าท่า ขันสกรูปลายด้านหน้าออก
18. JavaScript » JSON » Java - camelCase - เป็นเอกฉันท์
19. JavaScript » JSON » JavaScript - camelCase - ดั้งเดิม

ปัญหาเกี่ยวกับ Java

snake_caseยังคงเหมาะสมสำหรับผู้ที่มีรายการ Java เนื่องจากไลบรารี JSON ที่มีอยู่สำหรับ Java กำลังใช้วิธีการเข้าถึงคีย์แทนการใช้dot.syntaxมาตรฐานเท่านั้น ซึ่งหมายความว่ามันจะไม่เจ็บขนาดนั้นสำหรับ Java ในการเข้าถึงsnake_casedคีย์เมื่อเทียบกับภาษาการเขียนโปรแกรมอื่นซึ่งสามารถทำdot.syntaxได้

ตัวอย่างสำหรับ แพ็คเกจของ Javaorg.json

JsonObject.getString("snake_cased_key")

ตัวอย่างสำหรับ แพ็คเกจของ Javacom.google.gson

JsonElement.getAsString("snake_cased_key")

การใช้งานจริงบางอย่าง

• API ของ Google Maps JavaScript - camelCased
• API JavaScript ของ Facebook - snake_cased
• บริการเว็บของ Amazon - snake_cased & camelCased
• Twitter API - snake_cased
• JSON-LD - camelCased & ProperCamelCased

สรุปผลการวิจัย

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

อีกสิ่งที่ควรพิจารณาคือน้ำหนักที่จะวางบน JSON-generator เทียบกับ JSON-parser และ / หรือ front-end JavaScript โดยทั่วไปแล้วควรวางน้ำหนักเพิ่มเติมในส่วนของตัวสร้าง JSON แทนที่จะเป็นตัวแยกวิเคราะห์ JSON นี่เป็นเพราะตรรกะทางธุรกิจมักจะอยู่ในด้านตัวสร้าง JSON

นอกจากนี้หากไม่รู้จักด้าน JSON-parser คุณสามารถประกาศสิ่งที่ใช้ได้สำหรับคุณ

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

นี่เป็นเพราะเขตข้อมูล db มีคำย่อ / ตัวย่อจำนวนมากดังนั้นบางอย่างเช่นappSNSInterfaceRRTestดูยุ่งเล็กน้อย แต่app_sns_interface_rr_testเป็น nicer

ในตัวแปร Javascript ทั้งหมด camelCase และชื่อคลาส (ตัวสร้าง) เป็น ProperCase ดังนั้นคุณจะเห็นบางอย่างเช่น

var devTask = {
        task_id: 120,
        store_id: 2118,
        task_name: 'generalLedger'
    };

หรือ

generalLedgerTask = new GeneralLedgerTask( devTask );

และแน่นอนในคีย์ / สตริง JSON นั้นถูกห่อด้วยอัญประกาศคู่ แต่จากนั้นคุณเพียงใช้ JSON.stringify และส่งผ่านในวัตถุ JS ดังนั้นไม่จำเป็นต้องกังวลเกี่ยวกับเรื่องนั้น

ฉันดิ้นรนกับเรื่องนี้เล็กน้อยจนกว่าฉันจะพบสื่อความสุขนี้ระหว่างการประชุมการตั้งชื่อ JSON และ JS

ดูเหมือนว่ามีความหลากหลายมากพอที่ผู้คนจะหลีกเลี่ยงการอนุญาตให้มีการแปลงจากอนุสัญญาทั้งหมดไปสู่ผู้อื่น: http://www.cowtowncoder.com/blog/archives/cat_json.html

โดยเฉพาะอย่างยิ่งที่กล่าวถึงแจ็คสัน JSON parser bean_namingชอบ

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

Google ซึ่งเป็นหนึ่งใน บริษัท ด้านไอทีที่ใหญ่ที่สุดในโลกมีแนวทางแบบ JSON: https://google.github.io/styleguide/jsoncstyleguide.xml

การใช้ประโยชน์คุณสามารถค้นหาคู่มือสไตล์อื่น ๆ ซึ่ง Google กำหนดไว้ที่นี่: https://github.com/google/styleguide

ตามที่คนอื่น ๆ ระบุว่าไม่มีมาตรฐานดังนั้นคุณควรเลือกด้วยตัวเอง ต่อไปนี้เป็นสิ่งที่ควรพิจารณาเมื่อทำเช่นนี้:

1. หากคุณใช้ JavaScript เพื่อใช้ JSON ดังนั้นการใช้หลักการตั้งชื่อแบบเดียวกันสำหรับคุณสมบัติในทั้งสองอย่างนั้นจะให้ความมั่นคงทางสายตาและโอกาสในการใช้โค้ดที่สะอาดยิ่งขึ้น

2. เหตุผลเล็กน้อยที่ควรหลีกเลี่ยงกรณีเคบับคือยัติภังค์อาจปะทะกับ-อักขระที่ปรากฏในค่า

   {
     "bank-balance": -10
   }