coding style - CamelCase में शब्दकोष




coding-style camelcasing (8)

@ वैलेक्स ने जो कहा है, उसके अलावा, मैं इस प्रश्न के दिए गए उत्तरों के साथ कुछ चीजों को दोबारा जोड़ना चाहता हूं।

मुझे लगता है कि सामान्य उत्तर यह है: यह प्रोग्रामिंग भाषा पर निर्भर करता है जिसका आप उपयोग कर रहे हैं।

सी तेज

माइक्रोसॉफ्ट ने कुछ दिशानिर्देश लिखे हैं जहां ऐसा लगता है कि HtmlButton इस मामले के लिए कक्षा का नाम देने का सही तरीका है।

जावास्क्रिप्ट

जावास्क्रिप्ट में शब्दकोष के साथ कुछ वैश्विक चर हैं और यह उन सभी को ऊपरी मामले में उपयोग करता है (लेकिन मजेदार, हमेशा लगातार नहीं) यहां कुछ उदाहरण दिए गए हैं:

encodeURIComponent XMLHttpRequest toJSON toISOString

मुझे CamelCase के बारे में संदेह है। मान लीजिए कि आपके पास यह संक्षिप्त शब्द है: Unesco = United Nations Educational, Scientific and Cultural Organization.

आपको लिखना चाहिए: unitedNationsEducationalScientificAndCulturalOrganization

लेकिन अगर आपको संक्षिप्त नाम लिखने की ज़रूरत है तो क्या होगा? कुछ इस तरह:

getUnescoProperties();

क्या इसे इस तरह लिखना सही है? getUnescoProperties() OR getUNESCOProperties();


CamelCase में कनवर्ट करने के लिए, Google के (लगभग) निर्धारक ऊंट केस एल्गोरिदम भी है :

नाम के गद्य रूप से शुरुआत:

  1. वाक्यांश को सादा ASCII में कनवर्ट करें और किसी भी एस्ट्रोफ़ेस को हटा दें। उदाहरण के लिए, "मुल्लेर एल्गोरिदम" "मुएलर्स एल्गोरिदम" बन सकता है।
  2. इस परिणाम को शब्दों में विभाजित करें, रिक्त स्थान पर विभाजित करें और शेष बचे हुए विराम चिह्न (आमतौर पर हाइफ़न)।
    1. अनुशंसित: यदि किसी भी शब्द में पहले से ही सामान्य उपयोग में पारंपरिक ऊंट केस उपस्थिति है, तो इसे अपने घटक भागों में विभाजित करें (उदाहरण के लिए, "AdWords" "विज्ञापन शब्द" बन जाता है)। ध्यान दें कि "आईओएस" जैसे शब्द वास्तव में ऊंट मामले में नहीं हैं; यह किसी भी सम्मेलन की निंदा करता है, इसलिए यह सिफारिश लागू नहीं होती है।
  3. अब सब कुछ घटाएं (शब्दकोष समेत), फिर केवल प्रथम अक्षर को अपरकेस करें:
    1. ... ऊपरी ऊंट के मामले में, या प्रत्येक शब्द, या शब्द
    2. ... कम ऊंट मामले पैदा करने के लिए पहले को छोड़कर प्रत्येक शब्द
  4. अंत में, सभी शब्दों को एक पहचानकर्ता में शामिल करें।

ध्यान दें कि मूल शब्दों का आवरण लगभग पूरी तरह से अवहेलना है।

निम्नलिखित उदाहरणों में, "एक्सएमएल HTTP अनुरोध" सही ढंग से XmlHttpRequest में परिवर्तित हो गया है, XMLHTTPRequest गलत है।


कई सितारों (~ इस समय 57.5k) के साथ जिथब पर एयरबेंब जावास्क्रिप्ट स्टाइल गाइड है और शब्दकोष के बारे में मार्गदर्शिकाएं जो कहती हैं:

शब्दकोष और प्रारंभिकता हमेशा सभी पूंजीकृत होनी चाहिए, या सभी कम किए गए हैं।

क्यूं कर? नाम पठनीयता के लिए हैं, कंप्यूटर एल्गोरिदम को खुश करने के लिए नहीं।

// bad
import SmsContainer from './containers/SmsContainer';

// bad
const HttpRequests = [
  // ...
];

// good
import SMSContainer from './containers/SMSContainer';

// good
const HTTPRequests = [
  // ...
];

// also good
const httpRequests = [
  // ...
];

// best
import TextMessageContainer from './containers/TextMessageContainer';

// best
const requests = [
  // ...
];

जावास्क्रिप्ट एयरबिन स्टाइल गाइड acronyms । मूल रूप से:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

क्योंकि मैं आम तौर पर कक्षा के रूप में एक प्रमुख पूंजी पत्र पढ़ता हूं, इसलिए मैं इससे बचने लगता हूं। दिन के अंत में, यह सभी वरीयता है।


यूनेस्को एक विशेष मामला है क्योंकि यह आमतौर पर (अंग्रेजी में) एक शब्द के रूप में पढ़ता है और संक्षेप में नहीं - जैसे यूईएफए, राडा, बाफ्टा और बीबीसी, एचटीएमएल, एसएसएल के विपरीत


वर्तमान में मैं निम्नलिखित नियमों का उपयोग कर रहा हूं:

  1. XMLHTTPRequest लिए पूंजीगत मामला: XMLHTTPRequest , xmlHTTPRequest , requestIPAddress

  2. संक्षेप के लिए ऊंट का मामला: ID[entifier] , Exe[cutable] , App[lication] Exe[cutable] App[lication]

ID एक अपवाद है, क्षमा करें लेकिन सच है।

जब मुझे पूंजी पत्र दिखाई देता है तो मैं एक संक्षिप्त शब्द मानता हूं, यानी प्रत्येक पत्र के लिए एक अलग शब्द। संक्षेप में प्रत्येक अक्षर के लिए अलग-अलग शब्द नहीं होते हैं, इसलिए मैं ऊंट के मामले का उपयोग करता हूं।

XMLHTTPRequest है, लेकिन यह एक दुर्लभ मामला है और यह इतना अस्पष्ट नहीं है, तो यह ठीक है, नियमों और तर्क सौंदर्य से अधिक महत्वपूर्ण हैं।


स्वीकार्य उत्तर से guidelines की वैध आलोचनाएं हैं।

  • पात्रों की संख्या के आधार पर शब्दकोष / प्रारंभिकता का असंगत उपचार:
    • playerID बनाम playerId बनाम playerIdentifier
  • अगर वे पहचानकर्ता की शुरुआत में दिखाई देते हैं तो दो अक्षर वाले शब्दकोषों को अभी भी पूंजीकृत किया जाना चाहिए या नहीं:
    • USTaxes बनाम usTaxes
  • एकाधिक शब्दकोषों को अलग करने में कठिनाई:
    • यानी USID बनाम usId (या विकिपीडिया के उदाहरण में parseDBMXML )।

इसलिए मैं इस उत्तर को स्वीकृत उत्तर के विकल्प के रूप में पोस्ट करूंगा। वोट तय कर सकते हैं। सभी शब्दकोषों का लगातार इलाज किया जाना चाहिए; शब्दकोष किसी अन्य शब्द की तरह व्यवहार किया जाना चाहिए। विकिपीडिया उद्धरण :

... कुछ प्रोग्रामर संक्षेपों का इलाज करना पसंद करते हैं जैसे कि वे कम केस शब्द थे ...

तो मैं फिर से: ओपी का सवाल, मैं स्वीकृत उत्तर से सहमत हूं; यह सही है: getUnescoProperties()

लेकिन मुझे लगता है कि मैं इन उदाहरणों में एक अलग निष्कर्ष तक पहुंच जाऊंगा:

  • US TaxesusTaxes
  • Player IDPlayer ID

तो अगर आपको लगता है कि दो अक्षर के शब्दकोषों को अन्य शब्दकोषों के समान माना जाना चाहिए तो इस जवाब के लिए वोट दें।

ऊंट प्रकरण एक सम्मेलन है, एक विनिर्देश नहीं। तो मुझे लगता है कि लोकप्रिय राय नियम।

और मौजूदा कोड या मार्कअप में "लोकप्रिय" उत्तर की तलाश में, शायद स्वीकृत उत्तर सही हो गया।


getUnescoProperties() सबसे अच्छा समाधान होना चाहिए ...

जब संभव हो तो शुद्ध camelCase का पालन करें, जब आपके पास camelCase हो तो बस उन्हें ऊपरी केस दें जब अन्यथा camelCase

आम तौर पर ओओ प्रोग्रामिंग चर में लोअर केस लेटर ( lowerCamelCase ) से शुरू होना चाहिए और कक्षा को ऊपरी केस लेटर ( UpperCamelCase ) से शुरू करना चाहिए।

संदेह में जब शुद्ध camelCase जाओ;)

parseXML ठीक है, parseXml भी camelCase

XMLHTTPRequest XmlHttpRequest या xmlHttpRequest को बाद के ऊपरी केस xmlHttpRequest साथ जाने का कोई तरीका नहीं होना चाहिए, यह निश्चित रूप से सभी परीक्षण मामलों के लिए स्पष्ट नहीं है।

उदाहरण के लिए आप इस शब्द को HTTPSSLRequest , HTTP + SSL , या HTTPS + SL (जिसका अर्थ कुछ भी नहीं है ...), उस मामले में ऊंट केस सम्मेलन का पालन करें और httpSslRequest या httpsSlRequest लिए httpsSlRequest , शायद यह अब अच्छा नहीं है , लेकिन यह निश्चित रूप से अधिक स्पष्ट है।





acronym