2009-04-04 18 views
9

मैं यह पता लगाने की कोशिश कर रहा हूं कि सी # में निजी विधियों और निजी स्थैतिक तरीकों का नाम देने का सबसे बढ़िया तरीका क्या है।सी # में निजी और स्थैतिक निजी तरीकों का नामकरण करने का सबसे अच्छा अभ्यास क्या है?

पृष्ठभूमि: मुझे पता है कि निजी सदस्यों के लिए सबसे अच्छा अभ्यास underscore-prefix + camelcase है। आप मेरे साथ यह बहस कर सकते हैं, लेकिन मेरा विश्वास करो मैंने कट्टर पेशेवरों से पर्याप्त कोड देखा है जो इस सम्मेलन का पालन करते हैं, यह कुशल उद्योग मानक है।

मुझे यह भी पता है कि पास्कल केस सार्वजनिक तरीकों के लिए उद्योग मानक है। लेकिन मैंने निजी और निजी स्थैतिक तरीकों के लिए पास्कल केस, कैमलकेस, और अंडरस्कोर-प्रीफिक्स + कैमलकेस में टेस्ट स्टाइल नामकरण (यानी method_must_return_false_occasionally) का संयोजन देखा है।

लेकिन सी # में निजी और निजी स्थैतिक विधि नामकरण के लिए सबसे अच्छी अभ्यास शैली क्या है?

यदि कुछ शैलियों का उपयोग कुछ निजी तरीकों से किया जाता है और दूसरों के लिए नहीं, तो मैं समझ सकता हूं, बस समझाओ।

पढ़ने के लिए धन्यवाद।

उत्तर

16

बाहर चेक माइक्रोसॉफ्ट के Naming Guidelines और ब्रैड अब्राहम के Style Guide

वे कहते हैं कि सभी तरीकों PascalCase दिया जाना चाहिए कि

public void DoWork() {} 
private void StillDoWork() {} 
private static void ContinueToDoWork() {} 
+8

ठीक है, लेकिन मुझे आश्चर्य है क्योंकि जैसा कि हम सभी जानते हैं कि माइक्रोसॉफ्ट अत्यंत हो सकता है बुद्धिमान या बेहद हड्डीदार। ऐसा लगता है कि निजी तरीकों के लिए एक अलग सम्मेलन होने के कारण यह अधिक समझ में आता है, जैसे निजी सदस्यों के लिए एक अलग सम्मेलन है। इसके अलावा, स्पष्ट रूप से कुछ fxcops नियम मूर्ख हैं –

+0

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

+0

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

3

मैं उद्योग के मानकों के बारे में पता नहीं है, लेकिन यहां तक ​​कि निजी तरीकों और मैं के लिए पास्कल आवरण का उपयोग स्थिर तरीकों के लिए कोई भेद नहीं करते हैं।

6

एनईटी कक्षा पुस्तकालय विकास के लिए naming guidelines सार्वजनिक और निजी उपयोग के बीच अंतर नहीं करता है और स्थिर तरीकों के लिए Pascal मामले की सिफारिश करता है।

EDIT: मेरा व्यक्तिगत अभ्यास विधियों और गुणों के लिए पास्कल आवरण, फ़ील्ड, पैरामीटर और स्थानीय चर के लिए ऊंट आवरण का उपयोग करना है। कक्षा के भीतर से उदाहरण सदस्यों का संदर्भ देते समय मैं this. का उपयोग कक्षा सदस्यों और मानकों से अलग होने के लिए आवश्यक होने पर करता हूं। मुझे नहीं पता कि मैं "कट्टर समर्थक" के रूप में अर्हता प्राप्त करता हूं, लेकिन मुझे भुगतान मिलता है। :-)

EDIT 2: मूल रूप से लिखने के बाद से मैंने नौकरियां बदल दी हैं। हमारे द्वारा अनुसरण किए जाने वाले कोडिंग मानक मेरी व्यक्तिगत भावनाओं से अलग है और हम अंडरस्कोर के साथ निजी फ़ील्ड उपसर्ग करते हैं। मैंने रीशेपर का उपयोग करना शुरू कर दिया है और हमारे मानकों (आमतौर पर) डिफ़ॉल्ट नियमों का पालन करते हैं। मुझे लगता है कि मैं आसानी से अंडरस्कोर के साथ रह सकता हूं। मैं केवल this का उपयोग करता हूं जब बिल्कुल आवश्यक है क्योंकि यह हमारे कोड मानकों के अनुरूप नहीं है। संगठनात्मक व्यक्तिगत प्राथमिकता trumps।

+1

~ 35 के प्रतिनिधि के साथ कोई भी मेरी पुस्तक में एक कट्टर समर्थक है। – bendewey

+1

मैं भावना की सराहना करता हूं, लेकिन मुझे लगता है कि मुझे अभी भी बहुत कुछ सीखना है। – tvanfosson

+0

यह जानना अच्छा लगता है कि मैं अकेला व्यक्ति नहीं हूं जो 'इस' का उपयोग करता है। - कई बार मुझे बताया गया है कि यह कोड गंध है। – Sherlock

1

एक विकल्प के लिए एक उपकरण है कि आप एक समान होना चाहिए लागू करता है, इस तरह के style cop के रूप में (यदि आप reSharper का उपयोग वहाँ codeplex पर शैली पुलिस के लिए एक प्लगइन है) का प्रयोग है। अधिकांश टूल माइक्रोसॉफ्ट दिशानिर्देशों को लागू करने (? सुझाव) प्रतीत होते हैं क्योंकि ये आपको आपके कोड के एमएस प्लेटफॉर्म अनुमोदन के लिए कुछ परीक्षणों के माध्यम से प्राप्त करते हैं।

1

प्रत्येक स्थान जो मैंने काम किया है, हमेशा इसे अलग-अलग करता है।

मुझे लगता है कि एक पेशेवर डेवलपर के रूप में, पेशेवर का हिस्सा नई टीमों में फिट होने के बारे में है, जिसमें अलग-अलग कोडिंग सम्मेलन हो सकते हैं।

अपनी शैली को बदलने और संज्ञानात्मक विसंगति से निपटने में सक्षम होने के कारण यह पहले कुछ हफ्तों में बनाता है, पेशे का हिस्सा है।

मैं खुले स्रोत और इसी तरह की परियोजनाओं की विविधता को देखना शुरू कर दूंगा और आप विभिन्न प्रकार की योजनाएं देखेंगे।

मैंने अंडरस्कोर कैमलकेस और पास्कल केस डेबेट्स को विभाजित कम्युनिट्स और कभी-कभी टीमों को भी देखा है - जो मुझे कोडिंग योजना का बिंदु लगता है।

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

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

2

weird_underscore_naming सम्मेलन आमतौर पर परीक्षणों तक सीमित है क्योंकि यह उन्हें अधिक पठनीय बनाता है, और ऐसा कुछ है जिसे बीडीडी द्वारा अत्यधिक प्रोत्साहित किया जाता है। याद रखें, जबकि एक विधि संक्षेप में वर्णन करती है कि यह क्या करता है (DepositMoney), परीक्षणों को यह वर्णन करने की आवश्यकता है कि वे क्या कर रहे हैं, यानी Negative_deposits_must_be_caught

संबंधित मुद्दे