परिवर्णी शब्द के साथ CamelCase [बंद]


243

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

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

लेकिन क्या होगा अगर आपको परिचित लिखना है? कुछ इस तरह:

getUnescoProperties();

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


2
क्या यह प्रोग्रामर पर नहीं होना चाहिए।
पचेरियर

5
IMO को साँप_केस में परिवर्तित करना सबसे अच्छा समाधान है। क्या आपको पसंद है get_unesco_propertiesया get_u_n_e_s_c_o_properties?
jchook


जवाबों:


195

Microsoft ने कुछ दिशानिर्देशों के बारे में लिखा है camelCase:

जब का उपयोग किया जा रहा है, तो दो से अधिक वर्णों के समकाल के लिए पास्कल केस या ऊंट मामले का उपयोग करें। उदाहरण के लिए, का उपयोग करें HtmlButtonया htmlButton। हालाँकि, आपको ऐसे दो अक्षरों से युक्त समाहित करना चाहिए, जिनके System.IOबजाय केवल दो वर्ण हों System.Io

पहचानकर्ताओं या पैरामीटर नामों में संक्षिप्तिकरण का उपयोग न करें। यदि आपको संक्षिप्ताक्षरों का उपयोग करना है, तो दो वर्णों से अधिक के संक्षिप्त वर्णों के लिए ऊंट मामले का उपयोग करें, भले ही यह शब्द के मानक संक्षिप्त नाम का खंडन करता हो।

उपसंहार:

  • जब आप एक संक्षिप्त नाम या संक्षिप्त नाम का उपयोग करते हैं जो दो वर्ण लंबा होता है, उन सभी को कैप में रखें;

  • जब दृश्य दो वर्णों से अधिक लंबा हो, तो पहले वर्ण के लिए एक पूंजी का उपयोग करें।

तो, आपके विशिष्ट मामले में, getUnescoProperties()सही है।


11
मुझे लगता है कि मुझे IDइसके बजाय उपयोग करना शुरू करना चाहिए Id(जो मैं हर जगह उपयोग / देखता हूं)
जेसनस्क्रिप्ट

30
तकनीकी रूप से "आईडी" एक परिचित नहीं है (यह "पहचानकर्ता" या "पहचान" का एक संक्षिप्त नाम है), लेकिन मैं वास्तव में नहीं जानता कि यह कैसे / यदि यह दिशानिर्देश उस एक के साथ मदद करता है। : - \
ब्रायंट

64
मुझे नहीं लगता कि यह एक अच्छा मानक है। सामान्य शब्दों, दो-अक्षर वाले शब्दों, और सामान्य शब्दों के बीच अंतर होने से नामकरण अधिरोहित होने के विचार के विपरीत और अधिक लगता है।
सैम

40
इसके अलावा, माइक्रोसॉफ्ट द्वारा कहा जा रहा है कुछ "सही" नहीं है।
सैम

48
यह जानना अच्छा है कि वे अपने स्वयं के दिशानिर्देश का पालन करते हैं: XMLHttpRequest()मूल रूप से Microsoft से आया था।
मकेन

315

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

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

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

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

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

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

  • US TaxesusTaxes
  • Player IDplayerId

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

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

( EDIT: इस सुझाव को हटाकर कि वोटों को इस मुद्दे को तय करना चाहिए; जैसा कि @Brian David कहते हैं; स्टैक ओवरफ्लो "लोकप्रियता की प्रतियोगिता" नहीं है, और यह प्रश्न "राय आधारित" के रूप में बंद था)

भले ही कई लोग किसी अन्य शब्द की तरह समकितों का इलाज करना पसंद करते हैं, लेकिन अधिक सामान्य प्रैक्टिस के लिए सम-कैप्स को सभी-कैप्स में रखा जा सकता है (भले ही यह "घृणा" की ओर जाता है)

अन्य संसाधन:

  • ध्यान दें कि कुछ लोग संक्षिप्त नाम और संक्षेप के बीच अंतर करते हैं
  • नोट Microsoft दिशा-निर्देश दो-वर्ण वाले URL के बीच अंतर करते हैं, और "दो से अधिक वर्णों को जोड़ते हैं"
  • ध्यान दें कि कुछ लोग संक्षिप्त रूप से संक्षिप्तीकरण / संक्षेप से बचने की सलाह देते हैं
  • ध्यान दें कि कुछ लोग CamelCase / PascalCase से पूरी तरह बचने की सलाह देते हैं
  • ध्यान दें कि कुछ लोग "निरंतरता" के बीच "आंतरिक रूप से असंगत लगने वाले नियम" के रूप में भेद करते हैं (यानी दो-चरित्र के तीनों से अलग-अलग समरूपों का उपचार करते हैं); कुछ लोग "स्थिरता" को "समान नियम को लगातार लागू करने" के रूप में परिभाषित करते हैं (भले ही नियम आंतरिक रूप से असंगत हो)
  • फ्रेमवर्क डिजाइन दिशानिर्देश
  • Microsoft दिशानिर्देश

26
1) कोई असंगति नहीं है। "Id" एक संक्षिप्त नाम है , एक संक्षिप्त नाम नहीं है। 2) यह पहचानकर्ता के संदर्भ पर निर्भर करता है, अर्थात, वर्ग, इंटरफ़ेस, विशेषता, गणना प्रकार, स्थिर क्षेत्र, पैरामीटर, विधि, संपत्ति या घटना। यदि पहचानकर्ता के लिए दिशानिर्देश PascalCase का उपयोग कर रहा है, तो यह होगा USTaxesऔर PlayerId; ऊंट: usTaxesऔर playerId। 3) यह होगा USIdPascalCase में, usIdCamelCase में, और parseDbmXmlCamelCase में।
फ्रेडरिक क्राउटवल्ड

6
आप सही हैं, यह एक संक्षिप्त नाम है। मेरा कहना है कि यह UsTaxes, UsId होना चाहिए। दो-अक्षर "संक्षिप्त या संक्षिप्त" को तीन-अक्षरों, या अन्य "सामान्य शब्दों" से अलग नहीं माना जाना चाहिए। @ Eonil के उत्तर से अन्य सलाह, पूरी तरह से शॉर्टनर से बचने के लिए है। unitedStatesTaxes, या playerIdentifier।
लाल मटर

3
हा हा! मुझे संदेह है कि भ्रम पैदा होगा - बहुत - लेकिन दिशा-निर्देश, संभव भ्रम को रोकने के लिए अच्छी तरह से दिशानिर्देश हैं। एक विज्ञान के संदर्भ में एक आकस्मिक (खराब) संक्षिप्त उदाहरण: InIN(item)बनाम InIn(item)(संकेत: IN इंच (तों))। या, IDById(id)बनाम IdById(id), संदर्भ विज्ञान (संकेत: आईडी का अर्थ है संक्रामक रोग)। "दो अक्षर लंबे" - किस संदर्भ में?
फ्रेडरिक क्राउटवल्ड

2
पर माइक्रोसॉफ्ट लिंक "... का उपयोग पास्कल मामला या शब्दों के संक्षिप्त के लिए ऊंट मामले की तुलना में अधिक दो अक्षर लंबा । ... लेकिन, आप के संक्षिप्त रूप से मिलकर बनता है कि भुनाने चाहिए केवल दो पात्रों ..." यह हिस्सा मैं कहेंगे "असंगत है "। बेहतर लक्षण वर्णन "अपवाद" है। और कम से कम आपने तर्क दिया है कि दो अक्षर वाले शब्द अधिक भ्रम क्यों हो सकते हैं। लेकिन मुझे लगता है कि "कैनकैन" के साथ उन कार्यक्रमों को सिर्फ भाग्य से बाहर है; अस्पष्ट है कि यह डांस-मूव है या Cercle de l'Aviron de Nantes का कम्युनिटी एरिया नेटवर्क :)
रेड पी

18
के लेखक राजधानी अपराध: केमलकेस में लघुरूप संभाल कैसे सही ढंग से "abomination" शब्द का आह्वान जब वह लिखते हैं: "[का उपयोग कर अपरकेस के संक्षिप्त रूप] जबकि साधारण मामलों में काम करता है, यह घृणित कामों की ओर जाता है जब एक संक्षिप्त नाम एक और प्रकार है: HTTPURLConnection, XMLIDREF"
kghastie

21

सबसे पहले, मुझे स्पष्ट करना होगा कि मैं एक देशी अंग्रेजी वक्ता नहीं हूं, इसलिए अंग्रेजी व्याकरण के बारे में मेरा दावा केवल गलत हो सकता है। यदि आप ऐसी त्रुटियां खोजते हैं, तो कृपया मुझे बताएं, और मैं बहुत आभारी रहूंगा।


परिचित कराने के लिए सबसे अच्छा अभ्यास जितना संभव हो उतना कम से कम जिम से बचना होगा। वैसे भी, यह मामला नहीं है क्योंकि संक्षिप्त UNESCOनाम पूर्ण नाम से अधिक परिचित है UnitedNationsEducationalScientificAndCulturalOrganization

फिर, मुझे लगता UNESCOहै कि इससे अधिक समझ में आता है Unescoक्योंकि बस यह वास्तविक जीवन के रूप में इतना अधिक परिचित है। मुझे यह पता लगाने के लिए कुछ परेशानी थी कि Unescoवास्तव में इस शब्द का अर्थ क्या है।

एक अन्य उदाहरण के रूप में, सोचें Arc। यह एक चक्र के चारों ओर एक वक्र की तरह लगता है, लेकिन रस्ट में, इसका मतलब है Atomically Reference Counted। यदि यह ऐसा लिखा गया है ARC, तो कम से कम पाठक यह पहचानेंगे कि यह शब्द एक प्रकार के वक्र के बजाय किसी और चीज का एक संक्षिप्त रूप है।

आधुनिक कार्यक्रम मुख्य रूप से मानव पाठकों के लिए लिखे जाते हैं। फिर उन नामकरण नियमों को मशीन प्रसंस्करण या विश्लेषण के बजाय मानव पठनीयता के लिए निर्धारित किया जाना चाहिए ।

इस परिप्रेक्ष्य में, हम कुछ भी हासिल नहीं करते हुए Unescoअधिक उपयोग करके कुछ पठनीयता खो देते हैं UNESCO

और किसी भी अन्य मामलों के लिए, मुझे लगता है कि सादे पठनीयता नियमों (या सम्मेलनों) का पालन करना सर्वोत्तम पठनीयता के लिए अधिकांश मामलों के लिए पर्याप्त है


4
ऊपर दिए गए उदाहरण थोड़े भ्रामक हैं। "मैंने जो सबसे अच्छा दृष्टिकोण कभी देखा था वह था Apple ... इसका मतलब है कि एक उचित संज्ञा की तरह शब्दों का इलाज ... तो यूनेस्को अधिक समझ में आता है" - यही नहीं आप उचित संज्ञा कैसे लिखते हैं।
मिकको रैनतैन

@ मायको रेंटेन मैंने अपना जवाब अपडेट किया।
Eonil

7
वाह, मैं शायद ही उस जवाब में एक वाक्य पा
सकूँ

यह पूरी तरह से उस कोड के संदर्भ पर निर्भर करता है जिस पर आप काम कर रहे हैं या नहीं / संक्षिप्तीकरण कम या ज्यादा मायने रखता है। उदाहरण के लिए, मैं वित्त में काम करता हूं, और ऐसे बहुत से अनूठे शब्द हैं जो उद्योग में समान हैं और वास्तव में पूरी दुनिया में हैं। आप समय बर्बाद कर रहे होंगे और समरूप का उपयोग न करके अनावश्यक क्रिया-कलापों का निर्माण करेंगे, जो उस कंपनी में काम करने वाले हर व्यक्ति को दिल से जानता हो। उदाहरण के लिए वर्तमान मूल्य के लिए PV, भविष्य के मूल्य के लिए FV, औसत के लिए औसत, घातांक के लिए एक्सप आदि
विल एडिएगर

@ pm100 यह नहीं है कि मैंने क्या कहा? यूनेस्को यह नहीं है कि आप उचित संज्ञा कैसे लिखें।
मिको रानटेनन

17

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

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

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

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

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


17

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

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

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

जब संदेह सिर्फ शुद्ध हो camelCase;)

parseXMLठीक है, parseXmlहै भीcamelCase

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

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


2
मुझे आपका HTTPSSLउदाहरण पसंद है , हालांकि SL का कोई मतलब नहीं है, HTTPSSHTunnel जैसी किसी चीज़ के बारे में कैसे? क्या यह HTTPS + SH (शेल) या HTTP + SSH है? Google सम्मेलन निश्चित रूप से कम अस्पष्ट है।
एल। होलांडा

10

नहीं है Airbnb जावास्क्रिप्ट स्टाइल गाइड सितारों (~ इस पल में 57.5k) और के बारे में गाइड का एक बहुत साथ GitHub पर acronyms जो कहते हैं:

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

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

// 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 = [
  // ...
];

7
" क्यों? नाम पठनीयता के लिए हैं, कंप्यूटर एल्गोरिथ्म को खुश करने के लिए नहीं ", तो क्या XMLHTTPRequestयह XmlHttpRequestसही से बेहतर पठनीय है ?
एल। होलांडा

2
समझ में नहीं आता कि क्यों httpRequestsअच्छा माना जाता है लेकिन HttpRequestsबुरा है। तो XML HTTP अनुरोध के लिए इस सिद्धांत का पालन करना चाहिए xmlhttpRequest???
एल। होलांडा

1
मैं अक्सर AirBnb स्टाइल गाइड का हवाला देता हूं, लेकिन इस मामले में मैं सहमत नहीं हूं। मैं विशेष रूप से उनके बयान से सहमत नहीं हूं: "हर बार सभी शुरुआती और सभी निचले स्तर के लोगों को ऊपर-नीचे होना चाहिए।" मेरे विचार xmlHttpRequestसे अधिक पठनीय है XMLHTTPRequest
रोनन

3

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

  1. परिवर्णी शब्द के लिए राजधानी मामला: XMLHTTPRequest, xmlHTTPRequest, requestIPAddress

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

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

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

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


1

जावास्क्रिप्ट Airbnb शैली गाइड इस बारे में थोड़ी बात करती है । मूल रूप से:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

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


1

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

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

सी तेज

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

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

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

encodeURIComponent XMLHttpRequest toJSON toISOString


वैसे यह नेटस्केप पुराना है, यहां तक ​​कि इसमें कुछ भी नहीं है जैसे कैमल कैस onerror
एडी

1

अस्वीकरण: अंग्रेजी मेरी मातृ स्वर नहीं है। लेकिन मैंने लंबे समय से इस समस्या के बारे में सोचा है, जब डेटाबेस को संभालने के लिए नोड (कैमलकेस शैली) का उपयोग किया जाता है, क्योंकि टेबल फ़ील्ड्स का नाम सांप होना चाहिए, यह मेरा विचार है:

एक प्रोग्रामर के लिए 2 प्रकार के 'शब्दकोष' होते हैं:

  • प्राकृतिक भाषा में, यूनेस्को
  • कंप्यूटर प्रोग्रामिंग भाषा में, उदाहरण के लिए tmc and textMessageContainer, जो आमतौर पर एक स्थानीय चर के रूप में प्रकट होता है।

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

  1. जब हम प्रोग्रामिंग करते हैं, तो हमें एक चर को संक्षिप्त शैली या गैर-संक्षिप्त शैली में नाम देना चाहिए। इसलिए, यदि हम एक फ़ंक्शन का नाम getunESCOProperties है, तो इसका मतलब है कि यूनेस्को एक परिचित है (अन्यथा यह सभी बड़े अक्षर नहीं होना चाहिए), लेकिन जाहिर है, getऔर propertiesनहीं हैं। इसलिए, हमें इस फ़ंक्शन को या तो गनस्कोप नाम देना चाहिए या getUnitedNationsEducationScientificAndCulturalOrganizationProperties , दोनों अस्वीकार्य हैं।

  2. प्राकृतिक भाषा लगातार विकसित हो रही है, और आज के शब्दांश शब्द टोमोरो बन जाएंगे , लेकिन कार्यक्रम इस प्रवृत्ति से स्वतंत्र होने चाहिए और हमेशा के लिए खड़े होंगे।

वैसे, सबसे अधिक मत वाले उत्तर में, IO कंप्यूटर भाषा में अर्थ है (जिसका अर्थ है InputOutput), लेकिन मुझे यह नाम पसंद नहीं है, क्योंकि मुझे लगता है कि संक्षिप्त नाम (कंप्यूटर भाषा में) केवल नाम के लिए इस्तेमाल किया जाना चाहिए एक स्थानीय चर लेकिन एक उच्च-स्तरीय वर्ग / फ़ंक्शन, इसलिए IO के बजाय InputOutput का उपयोग किया जाना चाहिए


"जीभ", "टोन" नहीं
दान डैस्कलेस्क्यू

0

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


1
यह "समरूप" और मात्र "संक्षिप्त" के बीच का अंतर है; यह अंतर पूरी चर्चा के लिए प्रासंगिक प्रतीत होगा, लेकिन प्रस्तुत उत्तरों में लगभग पूरी तरह से चित्रित किया गया है।
सिमोन

बीबीसी, एचटीएमएल, एसएसएल, और अन्य शब्दकोष जहां आप प्रत्येक अक्षर को ध्वनि देते हैं उन्हें अधिक सटीक रूप से आद्याक्षर कहा जाता है। यूनेस्को जैसे शब्द जिन्हें एक शब्द के रूप में उच्चारित किया जाता है, सच्चे शब्द हैं।
लॉर्डव्हाइट

-2

एक और कैमलकेस सम्मेलन भी है जो बड़े HTMLअक्षरों (या) या लोअरकेस ( html) का उपयोग करके समरूपता के लिए पठनीयता का पक्ष लेने की कोशिश करता है , लेकिन दोनों ( Html) से बचता है ।

तो आपके मामले में आप लिख सकते हैं getUNESCOProperties। आप unescoPropertiesएक चर के लिए भी लिख सकते हैं , या UNESCOPropertiesएक वर्ग के लिए (वर्गों के लिए सम्मेलन अपरकेस के साथ शुरू करना है)।

यह नियम मुश्किल हो जाता है अगर आप एक साथ दो HTTP लगाना चाहते हैं, उदाहरण के लिए XML HTTP अनुरोध नामक वर्ग के लिए। यह अपरकेस के साथ शुरू होगा, लेकिन चूंकि XMLHTTPRequestइसे पढ़ना आसान नहीं होगा (क्या यह XMLH TTP अनुरोध है?), और XMLhttpRequestऊंट सम्मेलन को तोड़ देगा (क्या यह एक्सएम ल्हाटप अनुरोध है?), मामले को मिश्रण करने के लिए सबसे अच्छा विकल्प होगा XMLHttpRequest, जो है? वास्तव में W3C का उपयोग क्या है । हालाँकि इस तरह की नमाज़ों का उपयोग करना हतोत्साहित करता है। इस उदाहरण के लिए, HTTPRequestएक बेहतर नाम होगा।

चूँकि पहचान / पहचान के लिए आधिकारिक अंग्रेजी शब्द ID लगता है, हालाँकि यह एक संक्षिप्त विवरण नहीं है, आप वहीं नियम लागू कर सकते हैं।

यह सम्मेलन वहां काफी लोकप्रिय है, लेकिन यह सिर्फ एक सम्मेलन है और कोई सही या गलत नहीं है। बस एक सम्मेलन में जाने की कोशिश करें और सुनिश्चित करें कि आपके नाम पठनीय हैं।


3
मुझे विश्वास नहीं है कि यह पूरा धागा :-) तो यह XMLToHtmlConverter लेकिन HTMLToXmlConverter होगा? वाह ...
जोसफ सैबल

1
@ जोसेफस्लैब, हां, यह ऐसा ही होगा। आपके पतन के बारे में, मैं यह नहीं कह रहा हूं कि मुझे यह सम्मेलन पसंद है, लेकिन यह निश्चित रूप से मौजूद है।
जेसुअ कार्रेरा

1
मैंने सवाल पढ़ा "ऊंट मामले में Accron जिम लिखने का अच्छा सम्मेलन" नहीं "क्या आप सभी सम्मेलनों को सूचीबद्ध कर सकते हैं"। और जैसा कि मैं आपके उल्लेखित सम्मेलन को बहुत बुरा मानता हूं, मैंने
नाराज़ कर दिया

खैर सवाल यह है कि "क्या इसे इस तरह लिखना सही है?", और चूंकि इसे लिखने के कई "सही" तरीके हैं, क्योंकि यह सिर्फ एक सम्मेलन है, और यह सम्मेलन काफी लोकप्रिय है (आप इसे कैसे मानते हैं) की परवाह किए बिना, मेरे उत्तर बहुत ही मान्य है :-)
जेसुज करेरा
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.