JSON नामकरण कन्वेंशन [बंद]

Question

क्या JSON नामकरण पर एक मानक है? मैं अंडरस्कोर (लोअरकेस) द्वारा अलग किए गए सभी निचले मामलों का उपयोग करके सबसे अधिक उदाहरण देखता हूं। लेकिन, क्या आप PascalCase या CamelCase का उपयोग कर सकते हैं?

Comments

मैं उत्सुक था कि कुछ उद्योग के नेताओं ने क्या चुना। Twitter और Facebook API का उपयोग snake_case जबकि Microsoft और Google camelCase का उपयोग करते हैं।

— जस्टिन

@ जस्टिन क्योंकि ट्विटर रूबी का उपयोग कर रहा है और फेसबुक PHP का उपयोग कर रहा है। रूबी और PHP स्नेक_केस में हैं। Microsoft और Google क्रमशः C / .NET और जावा का उपयोग कर रहे हैं। ओह, यह सही है। नेट और जावा शायद कैमल कैस में हैं। यह सभी प्रोग्रामिंग भाषाओं के सम्मेलनों के बारे में है

— एबेल कैलेजो

कोई मानक नहीं है, लेकिन सम्मेलन को प्राप्त प्रणाली की तकनीक के मानक का उपयोग करना प्रतीत होता है।

— हेसेल का मार्टिन

सभी सही हैं कि JSON में नामों / कुंजियों के लिए कोई कठोर सम्मेलन नहीं है। हालांकि, मैं अत्यधिक कबाब-केस से बचने की सलाह देता हूं क्योंकि इसे जावास्क्रिप्ट () में नोटेशन द्वारा एक्सेस नहीं किया जा सकता है और इसे ऐरे [] नोटेशन का उपयोग करके एक्सेस किया जा सकता है जो मुझे लगता है कि थकाऊ है।

— सुरभ जूल

मुख्य रूप से राय-आधारित के रूप में बंद? ओपी प्रारूप की क्षमताओं / सीमाओं के बारे में तथ्यों के लिए पूछ रहा था, किसी की राय के लिए नहीं। उन्होंने कहा कि "आप कर सकते हैं", "आपको नहीं" करना चाहिए। शायद ओपी ने उन पांच व्यक्तियों के लिए स्पष्ट रूप से पर्याप्त शब्द नहीं कहा था, लेकिन आपको यह समझने की बजाय खराब पढ़ने की समझ होनी चाहिए कि वह क्या पूछ रहा है।

— डायनामिक जूल

Answer 1

कोई मानक नहीं है, लेकिन मैंने आपके द्वारा उल्लिखित 3 शैलियों को देखा है ("पास्कल / माइक्रोसॉफ्ट", "जावा" ( camelCase) और "सी" (अंडरस्कोर, snake_case)) - साथ ही साथ कम से कम एक और, kebab-caseजैसेlonger-name )।

यह ज्यादातर इस बात पर निर्भर करता है कि प्रश्न में सेवा के पृष्ठभूमि के डेवलपर्स क्या थे; c / c ++ बैकग्राउंड वाले (या ऐसी ही नामकरण को अपनाने वाली भाषाएँ, जिनमें कई स्क्रिप्टिंग भाषाएँ शामिल हैं, माणिक आदि) अक्सर अंडरस्कोर वैरिएंट चुनते हैं; और इसी तरह आराम करें (जावा बनाम .NET)। जैक्सन पुस्तकालय का उल्लेख किया गया था, उदाहरण के लिए, जावा बीन नामकरण सम्मेलन (camelCase )

अद्यतन: "मानक" की मेरी परिभाषा एक एकल सम्मेलन है। इसलिए जब कोई दावा कर सकता है "हाँ, कई मानक हैं", मेरे लिए कई हैं Naming Conventions, जिनमें से कोई भी "समग्र" मानक नहीं है। उनमें से एक को विशिष्ट प्लेटफ़ॉर्म के लिए मानक माना जा सकता है, लेकिन यह देखते हुए कि JSON का उपयोग उन प्लेटफार्मों के बीच अंतर के लिए किया जाता है जो बहुत समझदार हो सकते हैं या नहीं।

Comments

देवों की पृष्ठभूमि के साथ चिपके रहना महत्वपूर्ण है, लेकिन JSON जावास्क्रिप्ट मानक के साथ चिपक जाती है। आपका पहला कथन काफी सही नहीं है। लेकिन निश्चित रूप से अपनी टीम के नामकरण सम्मेलनों के साथ रहना।

— आबियान नोब

कुछ आंकड़ों को देखना दिलचस्प होगा, क्योंकि JSON और जावास्क्रिप्ट के बीच संबंध का दावा करने वाले लोगों के बीच लगातार घर्षण होता है (केवल ऐतिहासिक विरासत से परे), और जो लोग सोचते हैं कि वर्तमान में JSON को जावास्क्रिप्ट से जोड़ता है, बहुत कम है। मैं बाद वाले कैंप का हूं। लेकिन मैं रिश्तेदार उपयोग पैटर्न को जानने में दिलचस्पी होगी।

— स्टैक्मैन मैन 20'15

@StaxMan C # मामलों के बहुमत में PascalCase का उपयोग करता है, न कि CamelCase का।

— ArtOfCode

@ArtOfCode हाँ। तुम्हारा मतलब क्या है? (यह भी, पास्कल-केस को कभी-कभी "अपर कैमल केस" कहा जाता है)

— StaxMan

@StaxMan आप अपने जवाब को अपडेट करने के लिए

— गोगल्स

Answer 2

इस दस्तावेज़ में Google JSON स्टाइल गाइड (Google में JSON API के निर्माण के लिए अनुशंसाएँ),

यह अनुशंसा करता है कि:

1. प्रॉपर्टी के नाम ऊंटनी , ASCII तार होना चाहिए ।

2. पहला वर्ण एक अक्षर, एक अंडरस्कोर (_) या एक डॉलर चिह्न ($) होना चाहिए।

उदाहरण:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

मेरी टीम इस सम्मेलन का अनुसरण करती है।

Comments

जाहिरा तौर पर Google ने दिशानिर्देशों को बदल दिया है, ऊंट के मामले के बारे में कुछ भी नहीं पता है या अब दस्तावेज में _ या $ के साथ शुरू हो रहा है ...

— TheEye

@ यह अभी भी वहां है, आपको बस ड्रॉप डाउन पर क्लिक करने की आवश्यकता है।

— gdw2

अच्छी नजर, @ gdw2 भविष्य में अन्य लोगों के लिए, यदि आप तीर बटन पर क्लिक करते हैं Property Name Guidelines->Property Name Format->Choose meaningful property names.।

— पैंजरक्रिस

क्या कोई समझा सकता है कि आप एक संपत्ति के नाम को उपसर्ग करने के लिए अंडरस्कोर का उपयोग क्यों और कब करेंगे? एक संदर्भ उपयोगी होगा, न कि केवल एक राय।

— सीन ग्लोवर

Google का हवाला देते हुए एक स्पष्ट जवाब नहीं है। वे सिर्फ एक निश्चित सम्मेलन / दिशानिर्देश का समर्थन करते हैं और यह जावा को समझदार बनाता है क्योंकि वे बहुत जावा उन्मुख हैं।

— थॉमस आंद्रे वैंग

Answer 3

परिसर

JSON में कुंजियों का कोई मानक नामकरण नहीं है । ऑब्जेक्ट के अनुसार अनुभाग का नमूना:

JSON सिंटैक्स नाम के रूप में उपयोग किए जाने वाले स्ट्रिंग्स पर कोई प्रतिबंध नहीं लगाता है, ...

जिसका मतलब है कि कैमलकेस या स्नेक_केस ठीक काम करें।

ड्राइविंग कारक

एक JSON नामकरण सम्मेलन का आयोजन बहुत भ्रमित करने वाला है। हालांकि, यह आसानी से पता लगाया जा सकता है यदि आप इसे घटकों में तोड़ते हैं।

1. JSON उत्पन्न करने के लिए प्रोग्रामिंग भाषा

   • अजगर - snake_case
   • PHP - snake_case
   • जावा - कैमलकेस
   • जावास्क्रिप्ट - कैमलकेस

2. JSON में स्वयं कुंजियों का कोई मानक नामकरण नहीं है

3. JSON को पार्स करने के लिए प्रोग्रामिंग भाषा

   • अजगर - snake_case
   • PHP - snake_case
   • जावा - कैमलकेस
   • जावास्क्रिप्ट - कैमलकेस

घटकों को मिक्स-मैच करें

1. पायथन »JSON» पायथन - साँप_केस - एकमत
2. पायथन »JSON» PHP - स्नेक_केस - एकमत
3. पायथन » जैसन » जावा - स्नेक_केस - कृपया नीचे जावा समस्या देखें
4. पायथन »JSON» जावास्क्रिप्ट - साँप_केस समझ में आएगा; किसी भी रास्ते आगे-पीछे पेंच
5. पायथन »JSON» आपको नहीं पता - साँप_केस समझ में आएगा; वैसे भी पार्सर पेंच
6. PHP »JSON» पायथन - साँप_केस - एकमत
7. PHP »JSON» PHP - स्नेक_केस - एकमत
8. PHP »JSON» जावा - स्नेक_केस - कृपया नीचे जावा समस्या देखें
9. PHP »JSON» जावास्क्रिप्ट - snake_case समझ में आएगा; किसी भी रास्ते आगे-पीछे पेंच
10. PHP »JSON» आप नहीं जानते - snake_case समझ में आएगा; वैसे भी पार्सर पेंच
11. Java »JSON» पायथन - स्नेक_केस - कृपया नीचे जावा समस्या देखें
12. Java »JSON» PHP - snake_case - कृपया नीचे जावा समस्या देखें
13. जावा »जैसन» जावा - कैमलकेस - सर्वसम्मत
14. जावा »JSON» जावास्क्रिप्ट - कैमलकेस - एकमत
15. जावा »JSON» आप नहीं जानते - ऊंट का मतलब समझ में आएगा; वैसे भी पार्सर पेंच
16. जावास्क्रिप्ट »JSON» पायथन - साँप_केस समझ में आएगा; किसी भी रास्ते आगे-पीछे पेंच
17. जावास्क्रिप्ट »JSON» PHP - snake_case समझ में आएगा; किसी भी रास्ते आगे-पीछे पेंच
18. जावास्क्रिप्ट »JSON» जावा - कैमलकेस - एकमत
19. जावास्क्रिप्ट »JSON» जावास्क्रिप्ट - कैमलकेस - मूल

जावा की समस्या

snake_case अभी भी जावा प्रविष्टियों वाले लोगों के लिए समझ में आएगा क्योंकि जावा के लिए मौजूदा JSON लाइब्रेरी मानक dot.syntax का उपयोग करने के बजाय कुंजियों तक पहुँचने के लिए केवल विधियों का उपयोग कर रहे हैं । इसका मतलब है कि यह जावा का उपयोग करने के लिए है कि ज्यादा चोट नहीं होगा snake_cased अन्य प्रोग्रामिंग भाषा जो कर सकते हैं की तुलना में कुंजी dot.syntax ।

जावा के पैकेज के लिए उदाहरणorg.json

JsonObject.getString("snake_cased_key")

जावा के पैकेज के लिए उदाहरणcom.google.gson

JsonElement.getAsString("snake_cased_key")

कुछ वास्तविक कार्यान्वयन

• गूगल मैप्स जावास्क्रिप्ट एपीआई - ऊंटनी
• Facebook JavaScript API - snake_cased
• Amazon Web Services - snake_cased और camelCased
• Twitter API - snake_cased
• JSON-LD - camelCased और ProperCamelCased

निष्कर्ष

अपने JSON कार्यान्वयन के लिए सही JSON नामकरण सम्मेलन का चयन करना आपकी प्रौद्योगिकी स्टैक पर निर्भर करता है। ऐसे मामले हैं जहां कोई साँप_केस , कैमलकेस का उपयोग कर सकता है , या किसी अन्य नामकरण सम्मेलन का ।

विचार करने के लिए एक और चीज JSON-जनरेटर बनाम JSON-parser और / या फ्रंट-एंड जावास्क्रिप्ट पर डाला जाने वाला वजन है। सामान्य तौर पर, JSON-parser पक्ष के बजाय JSON-जनरेटर पक्ष पर अधिक भार डाला जाना चाहिए। ऐसा इसलिए है क्योंकि व्यावसायिक तर्क आमतौर पर JSON-जनरेटर पक्ष पर रहता है।

इसके अलावा, यदि JSON-parser पक्ष अज्ञात है, तो आप घोषणा कर सकते हैं कि आपके लिए क्या काम कर सकता है।

Comments

"Person":

— CamelCase

@stoft शायद ऐसा इसलिए है क्योंकि उन्होंने भी schema.org के सम्मेलन का अनुसरण किया था। बड़े अक्षर के साथ कुंजी शुरू करने का मतलब है कि यह एक शब्दावली इकाई है। लोअरकेस अक्षर के साथ कुंजी शुरू करने का मतलब है कि एक शब्दावली संपत्ति।

— एबेल कैलेजो

मैं इन विचारों से असहमत हूं, केवल इसलिए कि पायथन बैकएंड> जावा फ्रंटएंड कैमल कैस होना चाहिए, लेकिन फिर आप पायथन फ्रंटेंड को जोड़ते हैं और आपने बैकएंड और एक फ्रंटेंड से समझौता किया है। यह होना चाहिए कि बैकेंड के पास "मानक" है। फ्रंटेंड पार्सर्स को वैसे भी अनुकूलित करना आसान है

— बोजान कोगोज

यहां मेरी चिंता यह है कि "आपकी तकनीक" स्टैक का संदर्भ है। JSON के एक निर्माता को विशेष रूप से अगर HTTP सर्वर द्वारा सेवा दी जाती है, तो उसे इस बात का ज्ञान नहीं होना चाहिए कि कौन क्या खा रहा है या किन कारणों से। यदि JSON का उपयोग कई उत्पादकों और उपभोक्ताओं के बीच संचार की एक विधि के रूप में किया जाता है, तो निर्माता के प्रौद्योगिकी ढेर पर विचार नहीं किया जाना चाहिए।

— रॉबी वेयरहैम

@ रोबीवर्महम मैं किसी तरह उस पर सहमत हूं। यहाँ बात यह है कि "मानकों द्वारा" एक आधिकारिक नामकरण सम्मेलन नहीं है। तो इसके साथ ही, शायद किसी को "बाय फैक्टो" का विकल्प चुनना चाहिए, जो कि टेक्नोलॉजी स्टैक को देखना है। मुझे लगता है कि प्रौद्योगिकी स्टैक में जाना सबसे अच्छा तरीका है। फेसबुक पर एक नज़र डालें, क्या उन्होंने ऐतिहासिक रूप से जावास्क्रिप्ट का सम्मान किया और स्नेककेस का उपयोग किया? नाह! उन्होंने PHP के snake_case के साथ रहना चुना।

— हाबिल कालेजो

Answer 4

NodeJS पर मेरे लिए विशेष रूप से, अगर मैं डेटाबेस के साथ काम कर रहा हूं और मेरे क्षेत्र के नाम अंडरस्कोर अलग कर दिए गए हैं, तो मैं उन्हें संरचना कुंजियों में भी उपयोग करता हूं।

ऐसा इसलिए है क्योंकि db फ़ील्ड्स में बहुत से शब्दावलियाँ / संक्षिप्तीकरण हैं इसलिए appSNSInterfaceRRTest जैसा कुछ गड़बड़ दिखता है लेकिन app_sns_interface_rr_test अच्छा है।

जावास्क्रिप्ट वेरिएबल्स में सभी कैमकेलेज हैं और क्लास के नाम (कंस्ट्रक्टर) प्रॉपरकेस हैं, इसलिए आपको ऐसा कुछ दिखाई देगा

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

या

generalLedgerTask = new GeneralLedgerTask( devTask );

और निश्चित रूप से JSON कुंजी / स्ट्रिंग्स को दोहरे उद्धरण चिह्नों में लपेटा जाता है, लेकिन तब आप सिर्फ JSON.stringify का उपयोग करते हैं और JS ऑब्जेक्ट्स में पास होते हैं, इसलिए इसके बारे में चिंता करने की आवश्यकता नहीं है।

जब तक मुझे JSON और JS नामकरण सम्मेलनों के बीच यह खुशहाल माध्यम नहीं मिला, मैं इससे थोड़ा संघर्ष करता रहा।

Comments

मुझे भी। Android क्लाइंट पर snake_case के साथ JSON प्राप्त करना अजीब लगता है !! इसके अलावा डेटाबेस कॉलम नामों के लिए आवरण को अलग नहीं करता है, इसलिए डेटाबेस के लिए स्नेककेस सबसे अच्छा लगता है।

— पौराणिक

जावा में @mythicalcoder JSON अपने मूल में आंतरिक नहीं है। जावा केवल बाहरी पैकेज का उपयोग करता है org.json, जैसे जावा को पार्स करने के लिए gson। स्नेक_केस डेटा को प्राप्त करने से इतना नुकसान नहीं होता ...JSONObject.get('snake_case_key_here')

— एबेल कैलेजो

Answer 5

ऐसा लगता है कि पर्याप्त भिन्नता है कि लोग सभी सम्मेलनों से दूसरों को रूपांतरण की अनुमति देने के लिए अपने रास्ते से बाहर जाते हैं: http://www.cowtowncoder.com/blog/archives/cat_json.html

उल्लेखनीय रूप से, उल्लेखित जैक्सन जेन्सन पार्सर पसंद करते हैं bean_naming।

Comments

मामूली सुधार: जैक्सन ने बीन नामकरण सम्मेलन में चूक की, जो (कम) ऊंट प्रकरण है, जैसे beanNaming।

— स्टेक्समैन

Answer 6

मुझे लगता है कि JSON में आधिकारिक नामकरण सम्मेलन नहीं है, लेकिन आप कुछ उद्योग के नेताओं का अनुसरण करके देख सकते हैं कि यह कैसे काम कर रहा है।

Google, जो दुनिया की सबसे बड़ी आईटी कंपनी में से एक है, में JSON शैली मार्गदर्शिका है: https://google.github.io/styleguide/jsoncstyleguide.xml

लाभ उठाते हुए, आप अन्य स्टाइल गाइड पा सकते हैं, जिन्हें Google परिभाषित करता है: https://github.com/google/styleguide

Answer 7

जैसा कि दूसरों ने कहा है कि कोई मानक नहीं है, इसलिए आपको स्वयं को चुनना चाहिए। ऐसा करते समय कुछ बातों पर विचार करना चाहिए:

1. यदि आप JSON का उपभोग करने के लिए जावास्क्रिप्ट का उपयोग कर रहे हैं, तो दोनों में गुणों के लिए एक ही नामकरण सम्मेलन का उपयोग करके दृश्य स्थिरता प्रदान करेगा और संभवत: क्लीनर कोड के पुन: उपयोग के लिए कुछ अवसर।

2. कबाब-मामले से बचने का एक छोटा कारण यह है कि हाइफ़न उन -पात्रों के साथ नेत्रहीन रूप से टकरा सकते हैं जो मूल्यों में दिखाई देते हैं।

   {
     "bank-balance": -10
   }

Comments

स्नेक_केस अंडरस्कोर का उपयोग करता है, डैश नहीं।

— percebus