Konvensi Penamaan JSON [ditutup]


379

Apakah ada standar penamaan JSON? Saya melihat sebagian besar contoh menggunakan semua huruf kecil yang dipisahkan oleh garis bawah (huruf kecil). Tapi, bisakah Anda menggunakan PascalCase atau camelCase?


12
Saya ingin tahu apa yang dipilih beberapa pemimpin industri. Twitter dan Facebook API menggunakan snake_case sementara Microsoft dan Google menggunakan camelCase.
Justin

2
@Justin itu karena Twitter menggunakan Ruby dan Facebook menggunakan PHP. Ruby dan PHP dimasukkan ke snake_case. Microsoft dan Google masing-masing menggunakan C / .NET dan Java dengan baik. Oh itu benar. Net dan Java mungkin ke camelCase. Ini semua tentang konvensi bahasa pemrograman
Abel Callejo

1
Tidak ada standar, tetapi konvensi tampaknya menggunakan standar teknologi dari sistem penerima.
Martin dari Hessle

1
Semua sudah benar tidak ada konvensi ketat untuk nama / kunci di JSON. Padahal, saya sangat menyarankan untuk menghindari kebab-case karena tidak dapat diakses oleh notasi dot (.) Dalam javascript dan harus diakses menggunakan notasi array [] yang menurut saya membosankan.
saurabh

2
Ditutup terutama berdasarkan opini? OP meminta fakta tentang kemampuan / keterbatasan format, bukan untuk pendapat siapa pun. Dia berkata "dapatkah kamu", bukan "haruskah kamu". Mungkin OP tidak mengatakannya dengan cukup jelas untuk kelima orang itu, tetapi Anda harus memiliki pemahaman bacaan yang agak buruk untuk tidak memahami apa yang ia tanyakan.
dynamichael

Jawaban:


251

Tidak ada standar TUNGGAL, tetapi saya telah melihat 3 gaya yang Anda sebutkan ("Pascal / Microsoft", "Java" ( camelCase) dan "C" (garis bawah, snake_case)) - serta setidaknya satu lagi, kebab-caseseperti longer-name).

Sebagian besar tampaknya tergantung pada apa latar belakang pengembang layanan tersebut; mereka yang memiliki latar belakang c / c ++ (atau bahasa yang mengadopsi penamaan yang serupa, yang mencakup banyak bahasa skrip, ruby ​​dll) sering memilih varian garis bawah; dan sisanya serupa (Java vs .NET). Perpustakaan Jackson yang disebutkan, misalnya, mengasumsikan konvensi penamaan kacang Jawa (camelCase )

PEMBARUAN: definisi saya tentang "standar" adalah konvensi TUNGGAL. Jadi, sementara orang bisa mengklaim "ya, ada banyak standar", bagi saya ada banyak Naming Conventions, tidak ada yang "standar" secara keseluruhan. Salah satunya dapat dianggap sebagai standar untuk platform tertentu, tetapi mengingat JSON digunakan untuk interoperabilitas antar platform yang mungkin atau mungkin tidak masuk akal.


4
Tetap menggunakan latar belakang devs itu penting, tetapi JSON tetap menggunakan standar Javascript. Pernyataan pertama Anda tidak sepenuhnya benar. Tapi pasti tetap dengan konvensi penamaan tim Anda.
Anubian Noob

8
Akan menarik untuk melihat beberapa statistik, karena ada gesekan yang konstan antara orang-orang yang mengklaim koneksi antara JSON dan Javascript (di luar warisan sejarah), dan mereka yang berpikir ada sedikit saat ini yang menghubungkan JSON ke Javascript. Saya milik kamp terakhir. Tapi saya akan tertarik mengetahui pola penggunaan relatif.
StaxMan

@StaxMan C # menggunakan PascalCase di sebagian besar kasus, bukan camelCase.
ArtOfCode

@ Kode Kode ya. Apa maksudmu (juga, pascal-case kadang-kadang disebut "case unta atas")
StaxMan

@StaxMan, apakah Anda mempertimbangkan untuk memperbarui jawaban Anda untuk menyertakan penyebutan Googles Style Guide
garrettmac

402

Dalam dokumen ini Panduan Gaya Google JSON (rekomendasi untuk membangun API JSON di Google),

Ini merekomendasikan bahwa:

  1. Nama properti harus camelCased , string ASCII.

  2. Karakter pertama harus berupa huruf, garis bawah (_) atau tanda dolar ($).

Contoh:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

Tim saya mengikuti konvensi ini.


8
Rupanya Google telah mengubah pedoman, tidak menemukan apa pun tentang kasing unta atau mulai dengan huruf, _ atau $ dalam dokumen lagi ...
TheEye

32
@TheEye Masih ada di sana, Anda hanya perlu mengklik drop down.
gdw2

5
Mata yang bagus, @ gdw2. Untuk orang lain di masa depan, itu jika Anda mengklik tombol panah oleh Property Name Guidelines->Property Name Format->Choose meaningful property names..
Panzercrisis

3
Dapatkah seseorang menjelaskan mengapa dan kapan Anda akan menggunakan garis bawah untuk awalan nama properti? Referensi akan bermanfaat, bukan hanya pendapat.
Sean Glover

4
mengutip Google bukan jawaban yang tepat. mereka hanya mendukung konvensi / pedoman tertentu dan tampaknya java masuk akal karena mereka cukup berorientasi java.
Thomas Andreè Wang

186

Premis

Tidak ada penamaan standar kunci di JSON . Menurut bagian Objek dari spek:

Sintaks JSON tidak mengenakan batasan pada string yang digunakan sebagai nama, ...

Yang berarti camelCase atau snake_case harus bekerja dengan baik.

Faktor pendorong

Memaksakan konvensi penamaan JSON sangat membingungkan. Namun, ini dapat dengan mudah diketahui jika Anda memecahnya menjadi beberapa komponen.

  1. Bahasa pemrograman untuk menghasilkan JSON

    • Python - snake_case
    • PHP - snake_case
    • Java - camelCase
    • JavaScript - camelCase
  2. JSON sendiri tidak memiliki standar penamaan kunci

  3. Bahasa pemrograman untuk parsing JSON

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

Padu-padankan komponen

  1. Python »JSON» Python - snake_case - dengan suara bulat
  2. Python »JSON» PHP - snake_case - dengan suara bulat
  3. Python »JSON» Java - snake_case - silakan lihat masalah Java bawah ini
  4. Python »JSON» JavaScript - snake_case akan masuk akal; sekrup ujung depan
  5. Python »JSON» Anda tidak tahu - snake_case akan masuk akal; sekrup parser lagian
  6. PHP »JSON» Python - snake_case - dengan suara bulat
  7. PHP »JSON» PHP - snake_case - dengan suara bulat
  8. PHP »JSON» Java - snake_case - silakan lihat masalah Java di bawah ini
  9. PHP »JSON» JavaScript - snake_case akan masuk akal; sekrup ujung depan
  10. PHP »JSON» Anda tidak tahu - snake_case akan masuk akal; sekrup parser lagian
  11. Java »JSON» Python - snake_case - silakan lihat masalah Java di bawah ini
  12. Java »JSON» PHP - snake_case - silakan lihat masalah Java di bawah ini
  13. Java »JSON» Java - camelCase - dengan suara bulat
  14. Java »JSON» JavaScript - camelCase - dengan suara bulat
  15. Java »JSON» Anda tidak tahu - camelCase akan masuk akal; sekrup parser lagian
  16. JavaScript »JSON» Python - snake_case akan masuk akal; sekrup ujung depan
  17. JavaScript »JSON» PHP - snake_case akan masuk akal; sekrup ujung depan
  18. JavaScript »JSON» Java - camelCase - dengan suara bulat
  19. JavaScript »JSON» JavaScript - camelCase - Asli

Masalah java

snake_case akan tetap masuk akal bagi mereka yang memiliki entri Java karena pustaka JSON yang ada untuk Java hanya menggunakan metode untuk mengakses kunci alih-alih menggunakan dot.syntax standar . Ini berarti bahwa tidak ada salahnya bagi Java untuk mengakses kunci snake_cased dibandingkan dengan bahasa pemrograman lain yang dapat melakukan dot.syntax .

Contoh untuk paket Javaorg.json

JsonObject.getString("snake_cased_key")

Contoh untuk paket Javacom.google.gson

JsonElement.getAsString("snake_cased_key")

Beberapa implementasi aktual

Kesimpulan

Memilih konvensi penamaan JSON yang tepat untuk implementasi JSON Anda tergantung pada tumpukan teknologi Anda. Ada kasus di mana satu dapat menggunakan snake_case , CamelCase , atau konvensi penamaan lain.

Satu hal yang perlu dipertimbangkan adalah bobot yang harus diletakkan pada JSON-generator vs JSON-parser dan / atau JavaScript front-end. Secara umum, lebih banyak bobot harus diletakkan pada sisi generator JSON daripada sisi parser JSON. Ini karena logika bisnis biasanya berada di sisi generator JSON.

Juga, jika sisi JSON-parser tidak diketahui maka Anda dapat mendeklarasikan apa yang bisa bekerja untuk Anda.


2
"Person":bukan
camelCase

1
@stoft itu mungkin karena mereka juga mengikuti konvensi schema.org. Memulai kunci dengan huruf kapital berarti bahwa itu adalah entitas kosa kata. Memulai kunci dengan huruf kecil berarti itu adalah properti kosa kata.
Abel Callejo

2
Saya tidak setuju dengan ide-ide ini, hanya karena Python backend> Java frontend harus camelCase, tetapi kemudian Anda menambahkan Python frontend dan Anda telah mengkompromikan backend dan satu frontend. Seharusnya bagaimana backend memilikinya dengan "standar". Frontend parser lebih mudah beradaptasi
Bojan Kogoj

2
Perhatian saya di sini adalah bahwa ada referensi untuk tumpukan "teknologi Anda". Seorang produsen JSON terutama jika dilayani oleh server HTTP seharusnya tidak memiliki pengetahuan tentang siapa atau apa yang mengkonsumsinya, atau untuk alasan apa. Jika JSON digunakan sebagai metode komunikasi antara banyak produsen dan konsumen, maka tumpukan teknologi dari produsen seharusnya tidak menjadi pertimbangan.
Robbie Wareham

1
@RobbieWareham entah bagaimana saya setuju akan hal itu. Masalahnya di sini adalah "menurut standar" tidak ada konvensi penamaan resmi. Maka dengan itu, mungkin orang harus memilih "by de facto" yaitu melihat tumpukan teknologi. Saya pikir melihat ke tumpukan teknologi adalah cara terbaik untuk pergi. Lihatlah facebook, apakah mereka secara historis menghormati JavaScript dan menggunakan snakeCase? Tidak! Mereka memilih untuk tetap menggunakan snake_case PHP.
Abel Callejo

18

Khusus untuk saya di NodeJS, jika saya bekerja dengan basis data dan nama bidang saya digarisbawahi, saya juga menggunakannya dalam kunci struct.

Ini karena bidang db memiliki banyak akronim / singkatan sehingga sesuatu seperti appSNSInterfaceRRTest terlihat agak berantakan tetapi app_sns_interface_rr_test lebih baik.

Dalam variabel Javascript semua camelCase dan nama kelas (konstruktor) adalah ProperCase, jadi Anda akan melihat sesuatu seperti

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

atau

generalLedgerTask = new GeneralLedgerTask( devTask );

Dan tentu saja dalam kunci / string JSON yang dibungkus dengan tanda kutip ganda, tetapi kemudian Anda hanya menggunakan JSON.stringify dan lulus dalam objek JS, jadi tidak perlu khawatir tentang itu.

Saya berjuang dengan ini sedikit sampai saya menemukan media bahagia antara JSON dan konvensi penamaan JS.


1
sama disini. Menerima JSON dengan snake_case di klien Android terlihat canggung !! Juga basis data tidak membedakan casing untuk nama kolom, jadi snake_case tampaknya yang terbaik untuk basis data.
mitos pembuat

@mythicalcoder JSON di Java bukan intrinsik pada intinya. Java hanya menggunakan paket eksternal untuk parsing Jawa misalnya org.json, gson. Menerima data snake_case tidak terlalu menyakitkan seperti itu ...JSONObject.get('snake_case_key_here')
Abel Callejo

9

Tampaknya ada cukup banyak variasi yang dilakukan orang untuk memungkinkan konversi dari semua konvensi ke konvensi lain: http://www.cowtowncoder.com/blog/archives/cat_json.html

Khususnya, parser Jackson JSON yang disebutkan lebih suka bean_naming.


5
Koreksi kecil: Jackson default ke konvensi penamaan kacang Jawa, yang merupakan (lebih rendah) Casing Unta beanNaming.
StaxMan


0

Seperti yang orang lain katakan tidak ada standar, jadi Anda harus memilih sendiri. Berikut adalah beberapa hal yang perlu dipertimbangkan ketika melakukannya:

  1. Jika Anda menggunakan JavaScript untuk menggunakan JSON maka menggunakan konvensi penamaan yang sama untuk properti di keduanya akan memberikan konsistensi visual dan mungkin beberapa peluang untuk menggunakan kembali kode yang lebih bersih.

  2. Alasan kecil untuk menghindari kasus kebab adalah bahwa tanda hubung dapat berbenturan secara visual dengan -karakter yang muncul dalam nilai.

    {
      "bank-balance": -10
    }

1
snake_case menggunakan garis bawah, bukan garis putus-putus.
percebus
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.