कुछ प्रोग्रामिंग भाषाओं में अभी भी केस सेंसिटिविटी क्यों है?

44

मैं एक प्रोग्रामिंग भाषा में केस सेंसिटिविटी के लिए कोई भी प्रयोग नहीं देखता, इसके अलावा ओफ़्फ़सेटिंग कोड भी।

प्रोग्रामिंग भाषा में इसे क्यों लागू करें?

अपडेट करें:

ऐसा लगता है कि किसी ने आपको इस पर एक बयान दिया है ।

programming-languages syntax

— DavRob60
स्रोत

28

कुछ प्रोग्रामिंग भाषाओं में अभी भी असंवेदनशीलता क्यों है?

— थॉमस ईडिंग

1

यहां तक कि अंग्रेजी सामान्य रूप से केस-संवेदी है। आम उद्धृत उदाहरण पॉलिश और पोलिश है जो दो अलग-अलग शब्द हैं जिनके लिखित रूप केवल मामले में भिन्न हैं और जिनके अलग-अलग उच्चारण और अर्थ हैं। IMO प्रोग्रामिंग लैंग के लिए बेहतर है कि वह इस संबंध में बहुत चालाक न हो और प्रोग्रामर को स्वयं उपयुक्त लिखित सम्मेलनों के साथ आने दें। उदाहरण के लिए Person person = new Person()ओओ भाषा में कुछ लिखना सामान्य है जहां प्रतीक 'व्यक्ति' एक अस्थायी वस्तु है और 'व्यक्ति' एक वर्ग प्रकार है।

— ब्रैंडिन

113

जबकि केस तह अंग्रेजी में काफी तुच्छ है, यह कुछ अन्य भाषाओं में बहुत कम है। यदि एक जर्मन प्रोग्रामर ßएक चर नाम का उपयोग करता है, तो आप ऊपरी मामले के समकक्ष क्या विचार करने जा रहे हैं? केवल FYI करें, "is" का उपयोग केवल निचले मामले में किया जाता है। OTOH, "एस एस" है बराबर - आप एक संकलक उनकी बराबरी करने के लिए बाध्य पर विचार करेंगे? जब आप यूनिकोड में प्रवेश करते हैं, तो आपको और भी अधिक दिलचस्प समस्याएं मिलती हैं, जैसे कि पहले से रचे गए विशेषांक वाले वर्ण बनाम अलग-अलग संयोजन के साथ वर्णक। फिर आपको कुछ अरबी लिपियों में, दो के बजाय कई अक्षरों के तीन अलग-अलग रूपों के साथ मिलता है।

अंधेरे युग में अधिकांश प्रोग्रामिंग लैंग्वेज केस-इनसेन्सिटिव लगभग आवश्यकता से बाहर थे। उदाहरण के लिए, पास्कल ने कंट्रोल डेटा मेनफ्रेम पर शुरू किया, जिसमें प्रति चरित्र केवल छह बिट्स (64 कोड, कुल) का उपयोग किया गया था। ऐसी अधिकांश मशीनों में "सीडीसी साइंटिफिक" कैरेक्टर सेट का इस्तेमाल किया गया था, जिसमें केवल अपर-केस कैरेक्टर होते थे। आप अन्य वर्ण सेट पर स्विच कर सकते हैं, लेकिन अधिकांश में ऊपरी-मामला या निचला-मामला था, लेकिन दोनों नहीं - लेकिन दोनों के लिए समान कोड का उपयोग किया गया। प्राचीन ब्यूड कोड के बारे में भी यही बात थी और COBOL, FORTRAN, BASIC, आदि के शुरुआती दिनों में इस तरह के मानक को माना जाता था। जब तक अधिक सक्षम हार्डवेयर व्यापक रूप से उपलब्ध नहीं हो जाता, तब तक उनका केस-असंवेदनशील होना पूरी तरह से जटिल था, क्योंकि यह असंभव था। ।

समय के साथ, केस-असंवेदनशीलता की वास्तविक कठिनाई अधिक स्पष्ट हो गई है, और भाषा डिजाइनरों ने ज्यादातर फैसला किया है ("एहसास" शायद अधिक सटीक शब्द होगा) जब / यदि लोग वास्तव में केस असंवेदनशीलता चाहते हैं, तो यह बेहतर है कि सहायक उपकरण भाषा में ही।

कम से कम IMO, संकलक को इनपुट के रूप में बिल्कुल प्रस्तुत किया जाना चाहिए, यह तय नहीं करना चाहिए कि "आपने यह लिखा था, लेकिन मैं आपको यह मानने जा रहा हूं कि आपका मतलब कुछ और था।" यदि आप चाहते हैं कि अनुवाद होने हों, तो आप उन्हें अलग से करने से बेहतर हैं, उस उपकरण को अच्छी तरह से संभालने के लिए।

— जेरी कॉफ़िन
स्रोत

26

+1, कुछ ऐसा ही कहने जा रहा था, मेरे अनुभव में ज्यादातर लोग जो इस बारे में सचेत करते हैं, वे वही लोग हैं जो अन्य भाषाओं / चार सेटों पर विचार नहीं करते हैं।

— यिर्मयाह नून

5

मेरा बड़ा सवाल यह भी है कि अगर कंपाइलर अलग-अलग स्पेलिंग नोट करना शुरू कर दे, तो क्या यह आपको मनमाने ढंग से अंडरस्कोर करने की इजाजत दे सकता है? जब आप किसी पहचानकर्ता को मिस करते हैं तो क्या यह "वह करने की कोशिश करेगा जो आप उम्मीद करते हैं"? कितनी दूर जाएगी? (बीटीडब्ल्यू, एडीए स्पष्टता कारणों से संख्याओं के अंदर अनियंत्रित रूप से अनुमति देता है।)

— डैश-टॉम-बैंग

3

@ बैरी: दोनों बहुत अधिक समान हैं - पृथ्वी पर लगभग हर दूसरी भाषा में उन पात्रों की आवश्यकता होती है जो ASCII में उपलब्ध नहीं हैं। उस मामले के लिए, भले ही हम इसके द्वारा प्राप्त करते हैं, यह वास्तव में अंग्रेजी के लिए भी प्रतिबंधित है - उदाहरण के लिए, यह आपको "सहयोग" के रूप में "सहयोग" लिखने के लिए मजबूर करता है। सौभाग्य से, टाइपराइटर लोगों को कंप्यूटर के साथ आने से बहुत पहले इस तरह के प्रतिबंधों के आदी हो गए थे, इस बिंदु पर कि कुछ लोग सभी पात्रों का उपयोग करने की संभावना को एक बार आवश्यक मानते हैं।

— जेरी कॉफ़िन

2

@ डैश-टॉम-बैंग: कंपाइलर्स में लिखा गया है कि ऐसा करने की कोशिश की गई है (सही वर्तनी और क्या नहीं)। अनुभव बताता है कि आमतौर पर कंपाइलर को तेजी से चलाने और बेहतर त्रुटि संदेश देने के लिए बेहतर है।

— जेरी कॉफिन

2

@phresnel या "SZ"। दोनों के लिए अच्छे तर्क दिए जा सकते हैं।

— वेटिन

114

कोई भी असंवेदनशीलता क्यों चाहता है? किस परिदृश्‍य में एक ही चर को VARIABLEएक जगह, Variableदूसरी में और variableएक तिहाई में संदर्भित करना उपयोगी है ? मामला असंवेदनशीलता है। जब मैं अपने कोड में उस पर्ची की तरह केस-टाइपोस VAriableके Variableबजाय गलती से टाइप करता हूं, तो मुझे बहुत अधिक कंपाइलर त्रुटि मिलेगी ।

अंत में, कई प्रोग्रामिंग भाषाओं में न केवल ऐतिहासिक / जड़त्वीय कारणों के लिए संवेदनशीलता है, बल्कि इसलिए कि असंवेदनशीलता एक खराब विचार है।

— nohat
स्रोत

12

आप इसे अंदर-बाहर देख रहे हैं। हाँ, कई वर्तनी के साथ एक ही चर का जिक्र करना कष्टप्रद हो सकता है, लेकिन यह उतना ही बुरा है जितना कि दो अलग-अलग पहचानकर्ताओं का दो अलग-अलग चीजों का जिक्र करना, एक ही दायरे में, जो केवल मामले में भिन्न होते हैं। केस असंवेदनशीलता एक अच्छी बात है क्योंकि यह इसे रोकती है। (प्लस, यह सिंटैक्स त्रुटि बनने से एक सरल टाइपो रखता है; इस विषय पर जेफ की पोस्ट के प्रश्न में लिंक देखें।)

— मेसन व्हीलर

88

लेकिन मैं चाहता हूँ कि सरल टाइपोस वाक्यविन्यास त्रुटियाँ हों! मैं अपने कोड में सरल टाइपो नहीं चाहता और मैं चाहता हूं कि मेरा कंपाइलर मुझे उन्हें खोजने में मदद करे। केस की असंवेदनशीलता उन्हें ढूंढना कठिन बना देती है। केस असंवेदनशीलता सिर्फ मैला कोडिंग के लिए एक बहाना की तरह लगता है।

— नोहट

4

@ क्या: मैं मानता हूं, जब आप जो कुछ भी लिखना चाहते हैं उसके अलावा कुछ भी टाइप करते हैं, तो एक सिंटैक्स त्रुटि एक अच्छी बात है।

— टिम गुडमैन

13

@Mason व्हीलर, मैं है लेख पढ़ सकते हैं और मैं बस अधिक असहमत नहीं कर सका। मैंने केस-असंवेदनशील भाषाओं का भरपूर उपयोग किया है और मैं केस टाइपोस द्वारा लगातार बहिष्कृत हूं।

— नं।

11

नोहट के साथ बिल्कुल सहमत - केस असंवेदनशीलता एक हास्यास्पद विचार है - और आमतौर पर प्रस्तावक ऐसे लोगों से आते हैं जो अभी भी अच्छे पुराने वीबी / बेसिक दिनों के लिए तरस रहे हैं।

— टिम

27

जावा मामले में संवेदनशीलता का उपयोग कोड में अधिक विकल्प प्रदान करने के लिए नहीं किया जाता है, बल्कि बहुत स्पष्ट और सुसंगत अर्थ के लिए किया जाता है। ClassesLookLikeThis। objectsLookLikeThis। methodsLookLikeThis ()। STATIC_VARIABLES_LOOK_LIKE_THIS। Classes.WithInnerClassesLookLikeThis। यह अधिक से अधिक स्वतंत्रता प्रदान नहीं करता है: यह आपको कुछ जानकारी को संक्षेप में पैक करने की अनुमति देता है जो अन्यथा एक वर्बोज़ भाषा है।

मुझे लगता है कि बहुत अधिक संकलक और आईडीई समर्थन के साथ स्पष्ट रूप से टाइप किए गए भाषाओं में, केस-सेंसिटिविटी सूचना (जैसे, जावा) को संवाद करने का एक शानदार तरीका है। रूबी जैसी भाषाओं के साथ, केस असंवेदनशीलता शायद और भी अप्रत्याशित परिणाम देगी, हालांकि मैं केस-असंवेदनशील रूबी की कोशिश करूंगा।

मुझे लगता है कि एक सख्त प्रणाली के साथ संवेदनशीलता संवेदनशीलता कोड को बाधित नहीं करती है, लेकिन वास्तव में इसे स्पष्ट करती है। संभव जावा कोड पर विचार करें:

      joe blah = new hUf();

यह बहुत स्पष्ट है, लेकिन इसके बारे में क्या:

      hUf.WTF();

जावा के रूप में यह है, आप स्वचालित रूप से पता होगा कि यह क्या है। केस-असंवेदनशील जावा में, यह अस्पष्ट है, इसलिए आपको तरीकों से संकुल से उदाहरणों से वर्गों को अलग करने के लिए कुछ अन्य तंत्र का सहारा लेना होगा। और यह तंत्र शायद आपको उल्टी कर देगा कि यह कितना बदसूरत है :)

— दान रोसेनस्टार्क
स्रोत

2

नहीं! और अधिक नहीं !! int package_class_method_var_name? !!

— माइकल के

2

@Michael, अजीब है कि किसी को भी यह नहीं लगता है कि अंडरस्कोर टाइप करने के लिए एक परेशानी है।

— दान रोसेनस्टार्क

2

यह आपके कीबोर्ड पर निर्भर करता है। मेरे लिए (एक फ्रांसीसी कीबोर्ड का उपयोग करके), _ टाइप करना आसान है, {} बहुत कठिन हैं (उन तक पहुंचने के लिए AltGr का उपयोग करना)।

— फीलो

6

आह, इसलिए मामले की संवेदनशीलता नया हंगेरियन अंकन है।

— डेविड थॉर्नले

1

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

— रॉस पैटरसन

24

मुझे नहीं लगता कि इसे "लागू किया गया" इतना "अनुमति दी गई।" केस की संवेदनशीलता स्ट्रिंग तुलनाओं की डिफ़ॉल्ट स्थिति है; कंपाइलर इंजीनियर के लिए भाषा के मामले को असंवेदनशील बनाने के लिए अतिरिक्त काम करना पड़ता है, क्योंकि आपको केस-असंवेदनशील तुलना करने के लिए अतिरिक्त कोड में जोड़ने और सही त्रुटि और चेतावनी रिपोर्टिंग के लिए मूल टोकन नामों को संरक्षित करने की आवश्यकता होती है।

यह लगभग निश्चित रूप से क्यों यह सी में समाप्त हुआ; वे एक सरल भाषा बनाना चाहते थे जो प्रयोज्यता की कीमत पर एक संकलक को लागू करना आसान था। क्यों के रूप में यह आधुनिक भाषा में है? क्योंकि यह निश्चित रूप से सी में है, इसलिए इसे करने का सही तरीका होना चाहिए! </ कटाक्ष मोड>

— मेसन व्हीलर
स्रोत

3

इसके अलावा, मुझे लगता है कि 60 और 70 के दशक में जब प्रोग्रामिंग भाषाओं का आविष्कार किया जा रहा था, अंतरिक्ष और गति बहुत महत्वपूर्ण हैं। हम उन अतिरिक्त निर्देशों और केस-इनसेंसिटिव की तुलना के लिए जगह नहीं दे सकते। यह आधुनिक भाषाओं में "हमेशा जिस तरह से किया गया है" समस्या से अधिक है। ऐसा करने के लिए नई भाषाओं (जैसे C #) का कोई कारण नहीं है।

— Jay

1

@ जय: और फिर भी, किसी भी कारण से, पास्कल, जो सी से पहले और इसके डिजाइन को प्रभावित करता है, मामला असंवेदनशील है और अभी भी तेजी से संकलित करता है। ;)

— मेसन व्हीलर

@ मेसन: मुझे नहीं लगता कि पास्कल सी से प्रभावित थे ... मुझे इसे देखना था। असल में, वे सभी अल्गोल / फोरट्रान से आते हैं! people.mandriva.com/~prigaux/language-study/diagram.png

— जय

1

@Matt: उम्म ... तुम कहाँ से प्राप्त कर रहे हैं? सभी संसाधनों को मैंने पास्कल को 1970 और सी से 1972 तक देखा है।

— मेसन व्हीलर

16

आज के बच्चे। मेरे दिन में, हमारे पास कम मामला नहीं था, और हमें यह पसंद आया। 6 बिट्स पर्याप्त था। बेशक, अब हम सभी SHOUTING से बहरे हो गए हैं।

— 20

23

यदि और कुछ नहीं है, तो यह पार्सिंग को सरल करता है और आपको चर / वर्ग नामों के लिए अधिक संयोजन की अनुमति देता है।

केस-असंवेदनशील पार्सिंग के साथ, आप विशिष्ट पहचानकर्ताओं का उपयोग करने के लिए प्रतिबंधित होंगे, क्योंकि 'myClass' और 'MyClass' एक ही बात होगी। वैकल्पिक रूप से, आपको यह सुनिश्चित करने के लिए कि आपके पास कौन सा पहचानकर्ता संदर्भ के आधार पर उपयोग किया जाता है, यह निर्धारित करने के लिए आपको अपने पार्सर में जटिलता की परतों को जोड़ना होगा।

इस तरह एक मामले पर विचार करें:

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

मान लीजिए कि XmlWriter वर्ग में "लिखने" नामक एक स्थिर विधि है। क्या आप इसे उदाहरण के तौर पर या कक्षा में बुला रहे हैं, अगर यहाँ कोई केस-सेंसिटिविटी लागू नहीं होती है?

— एडम लीयर
स्रोत

14

हालांकि बुरा नामकरण सम्मेलन। मैं किसी का गला घोंट दूंगा अगर writeऔर Writeदो पूरी तरह से अलग तरीके थे।

— एलएलक्यू

5

इस पर TheLQ से सहमत होना होगा। यह मुझे पागल कर देता है जब मैं कुछ सी लाइब्रेरी में काम कर रहा होता हूं और मुझे "HWND hwnd;" जैसे घोषणाएं दिखाई देती हैं। जो भी इस oughtta की तरह संवेदनशीलता का दुरुपयोग करता है उसे बाहर निकाल कर गोली मार दी जाती है।

— मेसन व्हीलर 18

4

@LQ के तरीकों में एक ही मामला है। मैं अपने उदाहरण के रूप में वर्ग / चर नामों में विभिन्न मामलों का उपयोग कर रहा था।

— एडम लेअर

6

@ ए लर्न, मुझे लगता है कि यह एक बुरा उदाहरण है। एक असंवेदनशील भाषा के साथ, आपको इस बात की चिंता नहीं करनी चाहिए कि आपको किस विधि से कॉल करना है क्योंकि आपके पास पहले से ही एक वाक्यविन्यास त्रुटि होगी जो एक चर नाम के लिए एक वर्ग नाम का उपयोग करने की कोशिश कर रही है।

— मैट ओलेनिक

5

@ मैट आपको सिंटैक्स हाइलाइटिंग के बिना कोड नहीं करना चाहिए । मैं एक आईडीई के बिना समझ सकता हूं, लेकिन सिंटैक्स हाइलाइटिंग के बिना एक संपादक में कोडिंग ... कोई भी अपने आप से ऐसा क्यों करेगा?

— डेवि

13

मुझे केस सेंसिटिविटी पसंद है अगर किसी अन्य कारण से यह कोड को अधिक स्व-दस्तावेजीकरण बनाता है:

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

मैं आमतौर पर पायथन में कार्यक्रम करता हूं, लेकिन मेरे सी # दिनों में, मुझे कक्षा के नाम को कक्षा के समान ही सुविधाजनक लगता है, लेकिन कम (या ऊंट) मामले (जैसा कि अन्य ने कहा है):

Thing thing = new Thing();

केस-असंवेदनशील भाषाओं का उपयोग करने के लिए इसके लिए कुछ अन्य कन्वेंशन की आवश्यकता होती है, अर्थात, किसी प्रकार की सतर्कता जैसे:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

जो एक "बुरी बात" है।

मुझे एक वर्ग बनाम एक चर के उपयोग के संदर्भ में grep (केस-संवेदी) के लिए सुविधाजनक लगता है। केस-असंवेदनशील भाषा के साथ, यह कम आसान होगा। खोज और प्रतिस्थापन के लिए भी।

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

— Hollister
स्रोत

10

लोग वास्तव में उन्हें पढ़ने से पहले शब्दों के आकार पर ध्यान देते हैं। केस संवेदनशीलता एक प्रतीक के आकार को पूरे कोड के अनुरूप बनाए रखती है। मैं उस राज्य के ऊपर उन लोगों से भी सहमत हूं जो विभिन्न सम्मेलनों में विभिन्न प्रकार के प्रतीकों को दर्शाते हैं। केस संवेदनशीलता और असंवेदनशीलता दोनों का दुरुपयोग किया जा सकता है। खराब प्रोग्रामर हमेशा खराब कोड उत्पन्न करेंगे ... उन्हें एक रास्ता मिल जाएगा।

उदाहरण के तौर पर भाषा को लें। हम वाक्य क्यों शुरू करते हैं और राजधानियों के साथ चीजों को नाम दिया जाता है ... क्या यह यूनिक्स के कारण भी है?

— Tjaart
स्रोत

@ जस्ट टिप्पणियां स्पष्टीकरण मांगने के लिए हैं, न कि विस्तारित चर्चा के लिए। यदि आपके पास एक समाधान है, तो एक उत्तर छोड़ दें। यदि आपका समाधान पहले से ही पोस्ट किया गया है, तो कृपया इसे बढ़ाएँ। यदि आप इस उत्तर पर दूसरों से चर्चा करना चाहते हैं, तो कृपया चैट का उपयोग करें । अधिक जानकारी के लिए FAQ देखें ।

— एडम लेअर

9

मुझे लगता है कि C # और Java जैसे स्टेटिकली टाइप किए गए लैंगैगेज के लिए, यह वास्तव में कोई मूल्य नहीं जोड़ता है। क्योंकि ज्यादातर मामलों में, आपको एक IDE मिल गया है, जो वैसे भी आपके लिए ऑटो-सही केस बेमेल होगा, इसलिए दिन के अंत में, यदि मैं दुर्घटना से "VAriable" टाइप करता हूं, तो मेरा IDE ऑटो-सही हो जाएगा " चर "मेरे लिए। MyClass myClass;शैली सम्मेलनों में जोड़ें और आप देख सकते हैं कि केस-संवेदनशीलता जरूरी नहीं कि एक बुरी चीज है।

गतिशील रूप से टाइप की जाने वाली भाषाओं के लिए, एक तर्क के और अधिक हो सकते हैं, क्योंकि IDE के लिए एक स्वत: सुधार का अनुमान लगाना कठिन है, लेकिन गतिशील रूप से टाइप की गई भाषाओं के मामले में, आपको पहले से ही इस बारे में चिंता करने के लिए बहुत कुछ मिल गया है (के संदर्भ में) typos) कि एक सुसंगत आवरण सम्मेलन का उपयोग करने के लिए है कि बहुत अधिक बोझ जोड़ने के लिए नहीं जा रहा है।

तो हाँ, वहाँ कोई वास्तविक कारण भाषाओं सकता है, जबकि नहीं केस-संवेदी हो, वहाँ भी कोई वास्तविक कारण है कि वे है चाहिए या तो।

स्कॉट हैनेलमैन का यह लेख "साइनऑन" बनाम "साइनॉन" के बारे में स्ट्रिंग तुलना के बारे में था, और प्रोग्रामिंग भाषाओं के साथ कुछ भी नहीं करना था। मैं इस बात से सहमत हूं कि उपयोगकर्ताओं को हमेशा केस-असंवेदनशील की तुलना में टाइप करना चाहिए, लेकिन मुझे लगता है कि प्रोग्रामिंग भाषा में पहचानकर्ताओं के लिए एक अलग बॉलगेम है।

— डीन हार्डिंग
स्रोत

1

"IDE जो ऑटो-सही केस मिसमैच करता है" का उल्लेख करने के लिए +1

— DavRob60

3

IDEs wimps के लिए हैं। मैं पेंसिल और कागज के साथ कार्यक्रम करता हूं, और फिर कोड को स्कैन करता

— हूं

6

जब कोई भाषा केस-संवेदी होती है, तो मैं इसका फायदा उठाकर गणित और विज्ञान में पारंपरिक केस के उपयोग को पुन: पेश करता हूं। यहाँ कुछ मामलों के सम्मेलनों की सूची (बिना मतलब के संपूर्ण) है:

संभाव्यता सिद्धांत में, निचला मामला fआमतौर पर प्रायिकता घनत्व फ़ंक्शन (पीडीएफ) का Fप्रतिनिधित्व करता है , जबकि ऊपरी मामला संबंधित संचयी वितरण फ़ंक्शन (सीएफडी) का प्रतिनिधित्व करता है।
इसके अलावा प्रायिकता सिद्धांत में, अपर केस लेटर्स यादृच्छिक चर को दर्शाते हैं X, और संबंधित लोअर केस लेटर उनकी वास्तविकताओं को दर्शाते हैं x, जैसा कि $ Pr [X = x] \ leq 0.05 $ में है।
रैखिक बीजगणित में, ऊपरी केस पत्रों का उपयोग आमतौर पर मैट्रिस को संदर्भित करने के लिए किया जाता है, जबकि निचले केस पत्रों का उपयोग आमतौर पर संख्याओं को संदर्भित करने के लिए किया जाता है, जैसे, $ A = [a_ {ij}] $।
यूनिट प्रतीकों को लिटर (एल) को छोड़कर निचले मामलों के अक्षरों (जैसे, मीटर के लिए मीटर) और एक व्यक्ति (डब्ल्यू के लिए डब्ल्यू, पास्कल के लिए पा, न्यूटन के लिए एन, और इसी तरह) से व्युत्पन्न लिखा जाता है।
उपसर्गों के प्रतीकों का अर्थ है कि एक मिलियन या उससे अधिक का पूंजीकरण किया जाता है (एम फॉर मेगा (लाखों)), और जो एक मिलियन से कम हैं वे कम मामले हैं (मिली (हजार) के लिए मीटर)।

— अन्य
स्रोत

3

मान्य बिंदु, लेकिन आप लगभग हर सामान्य प्रोग्रामिंग भाषा के कोडिंग सम्मेलनों का उल्लंघन कर रहे होंगे, जो अपने स्वयं के प्रयोजनों के लिए केस संवेदनशीलता का उपयोग करते हैं ..

— केन ब्लूम

3

मुझे लगा कि यह यूनिक्स और सी की वजह से है - लेकिन यह एक तरह का चिकन और अंडे की समस्या है जिसका केवल गीजर ही ठीक से जवाब दे सकता है।

मैं तर्क का उपयोग करता हूं कि "द ईस्टर बनी कमिंग टू टाउन" में मुर्गियों का उपयोग तब किया गया जब उनसे पूछा गया कि क्या वे अंडे से पहले आए थे। क्योंकि नूह के सन्दूक पर मुर्गियाँ थीं, इसलिए मुर्गियाँ पहले आईं। इसलिए, क्योंकि जीसीसी यूनिक्स पर चलता है, यूनिक्स पहले आया था, इसलिए क्योंकि यूनिक्स मामले के लिए बहुत परवाह करता है, सी और इसके सभी वेरिएंट और वंशज, कुछ भी जो घुंघराले ब्रेसिज़ लगाता है, मामले की परवाह करता है।

शायद घुंघराले ब्रेसिज़ और केस सेंसिटिविटी के बीच भी एक कड़ी है।

— पीटर टर्नर
स्रोत

यूनिक्स जीसीसी से कई साल पहले आया था, लेकिन मूल बीसीपीएल संकलक यूनिक्स से पहले आया था, और इसने आमतौर पर "सी सिंटैक्स" बनाया।

— रॉस पैटरसन

2

अब तक दिए गए उत्कृष्ट उत्तरों के अलावा, मैं यह बताना चाहता हूं कि मामले की संवेदनशीलता आपको अतिरिक्त "नाम स्थान" भी देती है। उदाहरण के लिए पर्ल के कुछ विशेष ब्लॉक हैं BEGINऔर ENDजो सामान्य कोड की तुलना में अलग-अलग समय पर चलते हैं (संकलन के समय BEGIN, सामान्य प्रोग्राम समाप्त होने के बाद END), और ऑल-कैप के रूप में उन लोगों को बाहर खड़ा करता है, और इसका मतलब है कि निचला मामला वेरिएंट आरक्षित शब्द नहीं हैं।

कोई इससे भी आगे जा सकता है और भाषा के भविष्य के उपयोग के लिए सभी बड़े नामों को आरक्षित कर सकता है, और सामान्य प्रोग्रामर को कोई नुकसान नहीं पहुंचा सकता है, जो आमतौर पर उनके कोड के बारे में नहीं जानते हैं।

— Moritz
स्रोत

2

"मामला संवेदनशील" तकनीकी व्यक्तियों के लिए अस्पष्टता को कम करने के लिए हमेशा बेहतर होता है। एक उदाहरण के रूप में फ़ाइल नाम लें। विंडोज फ़ाइलनाम से निपटना यूनिक्स फ़ाइल नाम की तुलना में अधिक परेशानी है क्योंकि विंडोज में फ़ाइल नाम केस-असंवेदनशील है जबकि यूनिक्स में फ़ाइल नाम केस-संवेदी है।

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

— linquize
स्रोत

बकवास। यह केवल अस्पष्टता को कम करने के लिए प्रकट होता है क्योंकि आप पहले से ही केस-संवेदी व्यवहार की अपेक्षा करते हैं।

— रॉस पैटरसन

1

मैं इस शेख़ी से हैरान हूँ। अब जब कोई नहीं चाहता है कि आप m_सी # में एक अंडरस्कोर या एक फ़ील्ड नाम का उपयोग करें, तो मैं सिर्फ ऊंट मामले का उपयोग कर रहा हूं, और यदि फ़ील्ड का नाम सार्वजनिक संपत्ति के नाम के समान है, तो सार्वजनिक संपत्ति का नाम पास्कल मामला है और बैकिंग फ़ील्ड ऊंट का मामला है, मैं आंकड़ा देता हूं, "ऐसा हो" - यही बड़े पैमाने पर प्रोग्रामिंग समुदाय चाहता है। यह अब तक कोई समस्या नहीं हुई है।

— स्कॉट व्हिटलॉक
स्रोत

0

विशेष रूप से कुछ प्रोग्रामर बुनियादी दिनों के शुरुआती दिनों से आते हैं, जहां एक चर नाम केवल 2 वर्ण लंबा हो सकता है।

और इसलिए, जब यह किसी भी वर्ण का हो सकता है, तो वे बहुत खुश हो जाते हैं। और मामले की संवेदनशीलता के साथ - क्योंकि वे इस तरह की चीजों के कारण SomeNameगलती से बराबर होने SOMENAMEऔर बग पैदा करने की परवाह नहीं करना चाहते हैं ।

— माइकल डब्ल्यू
स्रोत