क्या कोई मुझे C # का कोडिंग कन्वेंशन समझा सकता है?


14

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

हालाँकि, C # के साथ मेरी सबसे बड़ी जिज्ञासा यह है कि यह अपने तरीके के नामों के पहले अक्षर (जैसे जावा: getPrime()C #: GetPrime()aka: पास्कल केस?) को बड़ा करता है। क्या इसका कोई अच्छा कारण है? मैं क्रैश कोर्स पृष्ठ से समझता हूं कि मैंने पढ़ा है कि जाहिरा तौर पर यह .Net के लिए सम्मेलन है और मेरे पास इसे बदलने का कोई तरीका नहीं है, लेकिन मैं यह सुनने के लिए उत्सुक हूं कि यह सामान्य (रिश्तेदार?) ऊंट मामले के विपरीत क्यों किया गया? कहते हैं, जावा का उपयोग करता है।

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


18
मैं वास्तव में आप देख सकते हैं नहीं लगता है camelCaseऔर PascalCaseऔर underscore_caseऔर कहते हैं कि उनमें से एक सामान्य बात है (यहां तक कि अपेक्षाकृत सामान्य) और दूसरों को नहीं। जैसा कि @dasblinkenlight ने कहा, यह एक मनमाना विकल्प है। केवल एक चीज जिससे आपको लगता है कि C # का कन्वेंशन असामान्य है, वह यह है कि आप "जावा में सामान्य रूप से प्रोग्राम करते हैं", और इस प्रकार जावा के लिए किए गए मनमाने विकल्प के आदी हैं।
कार्सॉन 63000 5

इसके बजाय जावास्क्रिप्ट का उपयोग करें .. यूनिटी 3 डी के लिए :)
लिप्स

@ लिपीसिस क्यों - व्यक्तिगत स्वाद के अलावा? ;-)
आयोडर

@AedonEtLIRA पूरी तरह से व्यक्तिगत .. कोई बात नहीं :) :) एकता का आनंद लें चाहे कोई भी भाषा हो .. आप का उपयोग करना समाप्त हो जाएगा ..
Lipis

@ लिपिस अब तक बहुत अच्छा है। घंटियाँ और सीटी और मैं अभी तक उस पर पैसा नहीं गिराया है। लेकिन मुझे C # (c / c ++) और जावा की संरचित शैली पसंद है।
ahodder

जवाबों:


27

नामकरण सम्मेलनों उनके प्रकाशक की मनमानी पसंद का प्रतिनिधित्व करते हैं। जावा में आपके तरीकों के नामकरण पर रोक लगाने के लिए स्वयं भाषा में कुछ भी नहीं है: जब तक कि पहला वर्ण एक अक्षर / अंडरस्कोर है, और अन्य सभी अक्षर अक्षर, अंक या अंडरस्कोर हैं, C # नहीं जा रहा है। शिकायत करते हैं। हालाँकि, .NET के साथ आने वाले क्लास लाइब्रेरी एक कन्वेंशन का अनुसरण करते हैं जिसे Microsoft ने आंतरिक रूप से अपनाया है। Microsoft ने इन दिशानिर्देशों को भी प्रकाशित किया , ताकि अन्य लोग उन्हें अपने स्वयं के कक्षा पुस्तकालयों के लिए भी चुन सकें। हालाँकि Microsoft के दिशानिर्देशों का पालन करना या अनदेखा करना आपकी पसंद है, लेकिन यदि आप एक ही नामकरण दिशानिर्देशों का पालन करते हैं तो अन्य लोगों द्वारा आपके कोड से परिचित होना तेज़ हो सकता है।


हालांकि एक सम्मेलन के पीछे आमतौर पर कुछ तर्क है, और जब मैंने पढ़ा "क्या इसके लिए एक अच्छा कारण है?" मैं इसे एक सवाल के बारे में समझता हूं कि क्यों नहीं।
ग्रीनल्डमैन

सार्वजनिक / आंतरिक / स्थिर सदस्यों और सभी तरीकों के लिए पास्कल। निजी के लिए ऊंट। जब आप इसे स्कैन करते हैं तो यह टोकन के दायरे को भेदने में मदद करता है। thisकीवर्ड एक ही करता है। शैली के विकल्प व्यावहारिक हैं, भले ही वे विदेशी दिखाई दें
Gusdor

23

शायद पास्कल / डेल्फी प्रभाव के कारण। C # और डेल्फी के निर्माता सभी (एंडर्स हेजलबर्ग) के बाद एक ही व्यक्ति थे।

डेल्फी कोडिंग सम्मेलनों द्वारा और बड़े पैमाने पर इस पहलू में सी # के समान होने के लिए; देख http://www.econos.de/delphi/cs.html#ObjectPascal_Procedures या http://wiki.delphi-jedi.org/index.php?title=Style_Guide#Method_Naming - संयोग?


4
ए 1 इसके लिए क्योंकि यह देता है कि यह वास्तविक कारण हो सकता है कि यह विशेष मनमाना विकल्प सी # के लिए क्यों बनाया गया था।
मैक्सिमस मिनिमस

4

किए गए अन्य उत्तरों के अलावा, तरीकों के लिए ऊंट मामले होने का मतलब है कि वे निजी सदस्यों, मापदंडों और विधि चर के नामों के साथ संघर्ष कर सकते हैं जो उनके नामकरण के लिए ऊंट मामले का उपयोग करते हैं। जावा (और C # 1.0) में यह बहुत सामान्य नहीं है क्योंकि प्रतिनिधि उपयोग अजीब और दुर्लभ है। आधुनिक C # में यह बिल्कुल सामान्य नहीं है , लेकिन यह भी अनसुना नहीं है।


1
अंडरस्कोर का उपयोग C # निजी क्षेत्रों में नहीं किया जाना चाहिए (देखें blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx , उदा), लेकिन यह विवादास्पद और अक्सर पाया जाता है।
जेन्स

1
भाषा निर्माणों के बीच अंतर करने के लिए आवरण पर भरोसा करना वास्तव में एक बुरा विचार है, भले ही भाषा आपको यह करने की अनुमति दे या नहीं।
gbjbaanb

4
@Telastyn वह बयान काफी चौंकाने वाला है। .NET क्लास लाइब्रेरी के अधिकांश लोग उस सम्मेलन का उपयोग करते हैं।
मैटवेवी

1
@ क्या यह अचानक मेरा सम्मेलन कैसे है ? मैं केवल एक टिप्पणी पारित कर रहा था, मैं इस मामले पर किसी भी तरह से एक राय नहीं है :)
18

2
@MarjanVenema: सुनिश्चित नहीं है कि आप किस बारे में बात कर रहे हैं, लेकिन C # काफी संवेदनशील है और आप निश्चित रूप से इसी तरह के कैस सदस्यों के बीच टकराव हो सकते हैं। यह मजेदार और रोमांचक हो जाता है जब आपके पास वास्तविक मामला होता है जैसे कि VB.NET जैसी सहज भाषाएं जो आप लाइब्रेरी स्तर पर काम कर रहे हैं।
वायट बार्नेट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.