स्टाइलकॉप की संभावनाओं का विस्तार

स्टाइलकॉप , शैली मिलान के लिए एक स्थिर सी # कोड विश्लेषक, 2008 की शुरुआत में आधिकारिक तौर पर जनता के लिए अनावरण किया गया था। आईटी मानकों के अनुसार, यह काफी समय पहले है, लेकिन किसी कारण से इस उपयोगी उपकरण को अभी तक व्यापक लोकप्रियता नहीं मिली है (कम से कम जो इसके योग्य है)।



नीचे मैं कारणों का विश्लेषण करने की कोशिश करूंगा, साथ ही स्टाइलकॉप के लिए नए प्लगइन के बारे में बात करूंगा।

---

स्टाइलकॉप बहुत लोकप्रिय क्यों नहीं है?

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



लेकिन यहां यह सवाल उठता है - आम तौर पर कोडिंग शैली से क्या समझा जाता है? क्या यह C # में लिखने वाले सभी लोगों के लिए किसी प्रकार की एकीकृत शैली है? या प्रत्येक टीम अपनी इच्छानुसार इसे चुनने के लिए स्वतंत्र है?



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



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



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

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

मैं स्थिति को कैसे ठीक कर सकता हूं?

सौभाग्य से, स्टाइलकॉप में एक काफी विकसित प्लग-इन सिस्टम है, जो इसकी कार्यक्षमता का विस्तार करने की अनुमति देता है (यहां तक ​​कि मूल नियमों का सेट भी तकनीकी रूप से एक अलग प्लग-इन के रूप में तैयार किया गया है)। लेकिन सार्वजनिक क्षेत्र में स्टाइलकॉप के लिए बहुत सारे प्लगइन्स नहीं हैं। और जो मिल सकते हैं उनमें से अधिकांश कुछ बिखरे हुए नियम हैं और छोड़ दिए गए हैं।



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

स्टाइलकॉप +

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



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



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

उन्नत नामकरण नियम

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



मैं दोहराता हूं, मैं यह नहीं कहता कि कौन सी शैली बेहतर है। लेकिन वास्तविकता यह है कि विभिन्न शैलियों पहले से मौजूद हैं (यहां तक ​​कि .NET बीसीएल में आप अलग-अलग समय पर अलग-अलग कमांड द्वारा लिखित कक्षाओं के समूहों का निरीक्षण कर सकते हैं - और अलग-अलग नामकरण शैलियों के साथ)। और यदि ऐसा है, तो शैली का पालन करने के लिए एक उपकरण बस इस सभी विविधता को ध्यान में रखने के लिए बाध्य है।



इस प्रकार, स्टाइलकॉप + में ऐसे नियम हैं जो आपको ऑब्जेक्ट्स के लगभग किसी भी सिस्टम को कॉन्फ़िगर करने की अनुमति देते हैं। कार्यात्मक रूप से, वे पूरी तरह से मूल नामकरण नियम ( SA13xx ) को कवर करते हैं, इसलिए उत्तरार्द्ध को बस बंद किया जा सकता है:







इन नियमों को कॉन्फ़िगर करने का तरीका ReSharper में समान सेटिंग्स के समान कई मायनों में है - आप संस्थाओं की एक विस्तृत श्रृंखला का उपयोग कर सकते हैं, जिनमें से प्रत्येक के लिए आप अपने स्वयं के नामकरण पैटर्न सेट कर सकते हैं।







उदाहरण के लिए, निम्न नियम कहता है कि नाम या तो उपसर्ग m_ से शुरू होना चाहिए, उसके बाद नाम ऊंटसाइल ( m_rulesMap ) में, या पूरी तरह से PascalStyle ( RulesMap ) में लिखा जाए ।







जैसा कि आप तस्वीर से देख सकते हैं, नामकरण पैटर्न में आप कई मैक्रोज़ का उपयोग कर सकते हैं जो पूंजीकरण की सबसे सामान्य शैलियों का वर्णन करते हैं।



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



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

अधिक कस्टम नियम

अन्य प्लगइन्स की तरह, स्टाइलकॉप + में स्टाइल की जाँच के लिए कई अतिरिक्त नियम हैं। उनमें से बहुत सारे अभी तक नहीं हैं, लेकिन जो मौजूद हैं वे काफी लचीले कॉन्फ़िगर हैं (सक्रिय उपयोगकर्ताओं के लिए धन्यवाद, जिन्होंने कई दिलचस्प विचारों का सुझाव दिया)।



इन नियमों के लिए एक अलग इंटरफ़ेस बनाया गया था, जो सेटिंग्स के अधिक अनुकूल संपादन के लिए अनुमति देता है ( नियम टैब पर पारंपरिक इंटरफ़ेस के विपरीत, यहां सेटिंग्स बुलियन मूल्यों के साथ झंडे तक सीमित नहीं हैं और स्वयं नियम पर लागू होती हैं)।

विस्तारित मूल नियम

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

// some statements ... { int a; // declaration of local variables required to set value of f1 ... this.f1 = ...; } { int a; // declaration of local variables required to set value of f2 ... this.f2 = ...; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इसका "परजीवी नियम" - SP1509 - में एक सेटिंग है जो इस वर्तनी को अनुमति देता है। मुख्य बिंदु यह है कि इस नियम में मूल कोड नहीं है जो मूल चेक को डुप्लिकेट करता है। इसके बजाय, "परजीवी नियम" स्टाइल कोड से मूल कोड लॉन्च करता है, लेकिन परिणाम पर अपने स्वयं के प्रतिबंध लगाता है (उपरोक्त उदाहरण में, यह "अंतर्निहित" कोड ब्लॉकों के कारण होता है) तो कोई त्रुटि उत्पन्न नहीं होगी।

एक निष्कर्ष के बजाय

यदि आप अभी तक StyleCop का उपयोग नहीं कर रहे हैं - तो इसे अवश्य आज़माएं, यह आपके लिए आवश्यक उपकरण बन जाना चाहिए!

यदि आपके पास कार्यक्षमता की कमी है, तो एक्सटेंशन लिखें या मौजूदा लोगों की तलाश करें!



स्टाइलकॉप + के लिए, यह विकसित करना जारी है। डाउनलोड, उपयोग, CodePlex पर प्रश्न पूछें। और अगर ऐसा होता है कि यह वह है जो स्टाइलकॉप का उपयोग शुरू करने के लिए कम से कम एक डेवलपर को संकेत देगा - हम मान सकते हैं कि इस परियोजना ने अपने मिशन को 100% पूरा किया!



सौभाग्य है

____________________

• http://stylecop.codeplex.com - CodePlex पर स्टाइलकॉप
• http://stylecopplus.codeplex.com - CodePlex पर स्टाइलकॉप +
• http://blogs.msdn.com/b/sourceanalysis - Microsoft StyleCop Blog
• http://devjitsu.com/blog - जेसन एलोर ब्लॉग