पर्ल :: आलोचना + तोड़फोड़ = एक टीम में आम कोडिंग प्रथाओं को लागू करना

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

2005 में, पर्ल समुदाय के एक सक्रिय सदस्य डेमियन कॉनवे ने पर्ल बेस्ट प्रैक्टिसेस बुक प्रकाशित की, जिसमें समझने योग्य, विश्वसनीय और समर्थित पर्ल कोड लिखने के लिए 256 सिफारिशें एकत्रित और संरचित की गईं। एक किताब से निचोड़ के साथ एक संक्षिप्त धोखा शीट यहां से डाउनलोड की जा सकती है ।

एक साल बाद, जेफरी थैलेमर और दोस्तों के एक समूह ने पर्ल को जारी किया : आलोचनात्मक , एक लचीला और एक्स्टेंसिबल फ्रेमवर्क, जो पर्ल कोड के सत्यापन को स्वचालित करता है ताकि यह सुनिश्चित हो सके कि यह कॉनवे की पुस्तक की अधिकांश सिफारिशों से मेल खाता है, साथ ही साथ कई अन्य अच्छे अभ्यास भी हैं।

पर्ल :: आलोचना को विभिन्न सॉस के तहत परोसा जाता है: सबसे पहले, एक ही नाम की उपयोगिता मॉड्यूल के साथ वितरित की जाती है - perlcritic, और दूसरी बात, कोड का परीक्षण के रूप में परीक्षण के रूप में जारी किया जा सकता है परीक्षण :: पर्ल :: आलोचक या टेस्ट # पर्ल :: आलोचक :: प्रगतिशील , तीसरी बात, आलोचक आसानी से VIM और Emacs में एकीकृत हो जाता है ।

इस नुस्खा में, मैं एक तोड़फोड़ भंडार के लिए प्रतिबद्ध होने पर फ्लाई पर पर्ल कोड की जांच करने के तरीके के बारे में बात करूंगा। बोन एपेटिट!

तोड़फोड़ में ट्रिगर तंत्र

कई अन्य संस्करण नियंत्रण प्रणालियों की तरह, तोड़फोड़, आपको प्रतिबद्ध प्रसंस्करण के निर्दिष्ट चरणों में मनमाने उपयोगकर्ता आदेशों को निष्पादित करने की अनुमति देता है। विशेष रूप से, तोड़फोड़ में एक pre-commit ट्रिगर (हुक) होता है, जो अंत में भंडार में आने से ठीक पहले लॉन्च किया जाता है। वास्तव में, यह केवल उसी नाम की शेल स्क्रिप्ट है जिसे तोड़फोड़ hooks/ रिपॉजिटरी डायरेक्टरी में खोजने की उम्मीद करता है। इसके तर्कों में से एक के रूप में, यह स्क्रिप्ट वर्तमान लेनदेन के पहचानकर्ता को प्राप्त करती है। इस पहचानकर्ता का उपयोग करते हुए, स्क्रिप्ट पूरी तरह से वर्तमान प्रतिबद्ध का विश्लेषण कर सकती है: कौन सी फाइलें या निर्देशिकाएं जोड़ी गईं, हटा दी गईं, बदल गईं, नई फ़ाइल सामग्री प्राप्त करें, अंतर करें, आदि। इस प्रयोजन के लिए, आप svnlook उपयोगिता या SVN :: लुक मॉड्यूल का उपयोग कर सकते हैं।

यदि pre-commit हुक 0 देता है, तो प्रतिबद्ध सुरक्षित रूप से सहेजा जाएगा, और यदि नहीं, तो संपूर्ण लेनदेन को अस्वीकार कर दिया जाएगा (यानी सभी फाइलें, निर्देशिका, संपत्ति परिवर्तन)। इस स्थिति में, STDERR को स्क्रिप्ट आउटपुट को svn-client पर पुनर्निर्देशित किया जाएगा। इस प्रकार, Perl::Critic pre-commit हुक के अंदर Perl::Critic करके, आप उल्लंघन कोड को रिपॉजिटरी में प्रवेश करने से रोक सकते हैं।

सिद्धांत से अभ्यास तक

1. डाउनलोड और perlcritic-checker.pl स्क्रिप्ट स्थापित करें

 wget http://perlcritic-checker.googlecode.com/files/perlcritic-checker-1.2.6.tar.gz
 tar -xzf perlcritic-checker-1.2.6.tar.gz
 सीडी पर्क्लक्रिटिक-चेकर-1.2.6
 perl ./Makefile.PL
 मेकअप
 परीक्षण करें
 सुडोल बनाते हैं

डिफ़ॉल्ट रूप से, स्क्रिप्ट और प्रलेखन /usr/local में स्थापित किया जाएगा।

2. एक परीक्षण SVN रिपॉजिटरी बनाएं

 निर्यात SVN_REPO = / tmp / svn_repo
 svnadmin $ SVN_REPO बनाते हैं

3. कॉन्फ़िगरेशन फ़ाइलों को स्थापित करें

सबसे पहले, perlcritic-checker विन्यास स्थापित करें:

 बिल्ली> $ SVN_REPO / हुक / perlcritic-checker.conf << 'EOF'
 #
 # perlcritic- चेकर का विन्यास उदाहरण
 #
 {
     # प्रगतिशील मोड: {0 | 1} |  प्रगतिशील मोड में perlcritic-checker
     # मौजूदा उल्लंघनों के बारे में शिकायत नहीं करता है लेकिन रोकता है
     # नए को शुरू करना।  पर्ल लागू करने के लिए अच्छी सुविधा :: समालोचक
     # मौजूदा परियोजनाओं के लिए धीरे-धीरे।
     प्रगतिशील_मोड => 1,

     # आपातकाल लगाता है: {0 | 1} |  ऐसे हालात हैं जब आपको * ज़रूरत * होती है
     # सभी चेक (जैसे आपातकालीन बग फिक्स) को दरकिनार कर परिवर्तन करने के लिए।
     # यह करतब आपको Perl :: Critic को "जादू" उपसर्ग का उपयोग करने की अनुमति देता है
     # टिप्पणी संदेश, उदाहरण के लिए: svn ci -m "NO CRITIC: I am in जल्दी" FooBar.pm
     allow_emergency_commits => 1,

     # ऊपर वर्णित मैजिक उपसर्ग को अनुकूलित किया जा सकता है:
     आपातकालीन_करण_समर्थक => 'कोई क्रेडिट',

     # उल्लिखित उल्लंघनों की अधिकतम संख्या सीमित करें।  यह पैरामीटर काम करता है
     # अलग तरीके से सख्त और प्रगतिशील तरीके से।  सख्त मोड में
     # उल्लंघन की लंबी सूची को तोड़ देगा: केवल एन सबसे गंभीर उल्लंघन
     # दिखाया जाएगा।  प्रगतिशील मोड में इस तरह के व्यवहार का कोई मतलब नहीं है,
     # यही कारण है कि उपयोगकर्ता को स्थानीय स्तर पर लंबन चलाने के लिए कहा जाएगा।
     #
     # वास्तव में, यह पैरामीटर जेनेरिक में एक सूक्ष्म बग के लिए एक समाधान है
     # svn- क्लाइंट जो तब होता है जब svn हुक (यानी perlcritic-checker.pl)
     # आउटपुट बहुत अधिक डेटा: svn-client सिर्फ रिपोर्ट करता है "कनेक्शन बंद हो गया
     # अप्रत्याशित रूप से "। इस बग को कई अतिरिक्त पुन: उत्पन्न करने के लिए।"
     # शर्तें पूरी होनी चाहिए:
     # - रिपोजिटरी एक्सेस स्कीम: 'svn: //' (svnerve daemon)
     # - विभिन्न मशीनों पर ग्राहक और सर्वर
     # - linux पर svn-client और -server चल रहे हैं
     #
     # यदि आप भी इसी समस्या का सामना कर रहे हैं, तो नीचे दिए गए विकल्प का उपयोग करने का प्रयास करें।
     # max_violations => 50,

     # एसवीएन रिपॉजिटरी पथ - टू - पर्ल :: क्रिटिक की प्रोफाइल मैपिंग।
     #
     # यह सुविधा आपको अलग पर्ल लागू करने की अनुमति देती है :: आलोचक
     # रिपॉजिटरी में विभिन्न रास्तों के लिए नीतियां।  उदाहरण के लिए,
     # आप ब्रांड-नई परियोजनाओं के साथ बहुत सख्त हो सकते हैं
     # कुछ मौजूदा परियोजना के लिए भोग और पूरी तरह से अक्षम
     # ऑटो-जनरेट या थर्ड-पार्टी कोड की जाँच।
     #
     # प्रत्येक संशोधित (जोड़ा, अद्यतन, प्रतिलिपि, स्थानांतरित) फ़ाइल नाम में
     # रिपॉजिटरी का मिलान नीचे दिए गए पैटर्न के अनुक्रम से किया जाता है।
     # ध्यान रखें, * अंतिम * मिलान नियम - जीत।
     #
     # प्रोफ़ाइल पथ पूर्ण या सापेक्ष हो सकते हैं।  बाद में
     # मामला वे $ REPOS / हुक / perlcritic.d निर्देशिका के तहत मैप किया जाएगा।
     प्रोफाइल => [

         # डिफ़ॉल्ट रूप से बहुत सख्त प्रोफ़ाइल लागू करें
         {पैटर्न => qr {[।] (दोपहर | pl | t) $},
             प्रोफ़ाइल => 'लंबित- brutal.conf')
         }
     ]
 }
 EOF

यह कॉन्फ़िगरेशन कहता है कि Perl::Critic 'सभी *.pm , *.pl और *.t फ़ाइलों के लिए एक सेटिंग perlcritic-brutal.conf से ली जानी चाहिए। हम प्रगतिशील मोड (नीचे पढ़ें) को सक्षम करते हैं और आपातकालीन कमिट्स को सक्षम करते हैं, अर्थात। कौन से कमिट चेक नहीं किए गए हैं ( NO CRITIC )।

अगला चरण Perl::Critic profile ( perlcritic-brutal.conf ) को इंस्टॉल करना है, जिसे हमने पिछली फाइल में संदर्भित किया है:

 mkdir $ SVN_REPO / हुक / perlcritic.d
 cat> $ SVN_REPO / हुक / perlcritic.d / perlcritic-brutal.conf << 'EOF'
 #
 # पर्ल :: आलोचना प्रोफ़ाइल उदाहरण
 #

 # परिधि को बहुत सटीक बनाएं
 गंभीरता = क्रूर

 # आप 1 से 11 तक किसी भी स्तर का चयन कर सकते हैं, लेकिन 8 की सिफारिश की जाती है
 क्रिया = 8

 # उनकी गंभीरता के स्तर के आधार पर उल्लंघनों को रंग दें
 रंग = १

 # यदि इस फ़ाइल में त्रुटियाँ हैं तो रुकें
 प्रोफाइल-सख्ती = घातक

 # नीतियों के केवल दो समूहों को सक्षम करें: कोर और पर्ल बेस्ट प्रैक्टिस
 विषय = कोर ||  PBP

 # स्पष्ट रूप से पर्ल के लिए पूरा रास्ता सेट करें :: साफ सुथरा विन्यास
 [CodeLayout :: आवश्यकता अनुसार]
 perltidyrc = / etc / perltidyrc
 EOF

इस प्रोफ़ाइल में आलोचक के संचालन का सबसे कठोर मोड ( severity = brutal ) शामिल है, जिसमें वह छोटी चीज़ों के साथ भी गलती पाएगा (हालाँकि, हम जानते हैं कि विमानन में कोई छोटी चीज़ नहीं है)। theme निर्देश इंगित करता है कि उपलब्ध पॉलिसी के पूरे सेट में से, और लगभग डेढ़ सौ हैं, केवल वे जो कोर या पर्ल बेस्ट प्रैक्टिसेस समूहों में हैं, उन्हें जांचना चाहिए। हम स्पष्ट रूप से perltidy कार्यक्रम की सेटिंग्स के लिए पथ को इंगित करते हैं, स्वचालित रूप से पर्ल कोड को प्रारूपित करने के लिए एक उपयोगिता। एक प्रारूपण उल्लंघन उन कारणों में से एक है, जिनके कारण कोई प्रतिबद्ध विफल हो सकता है।

मैं ध्यान देता हूं कि इस प्रोफ़ाइल में केवल मूल सेटिंग्स हैं, लेकिन यह एक अच्छा प्रारंभिक बिंदु है। आप दस्तावेज़ में Perl::Critic की विशेषताओं के बारे में अधिक पढ़ सकते हैं: perldoc Perl::Critic ।

अगला, हम perltidy लिए कॉन्फ़िगरेशन perltidy (रूट विशेषाधिकारों के साथ):

 सूदो सु -
 बिल्ली> / etc / perltidyrc << 'EOF'
 --perl-best-practices
 EOF
 निकास

यह फ़ाइल बेहद सरल है: यह पहले से उल्लिखित पर्ल बेस्ट प्रैक्टिस बुक की सिफारिशों के अनुसार कोड perltidy निर्देश perltidy । यदि आप एक अलग शैली के लिए उपयोग किए जाते हैं, तो perltidy (1p) मैनुअल पेज आपको आवश्यक स्वरूपण विकल्पों को चुनने में मदद करेगा।

फ़ाइल का नाम और पथ बेतरतीब ढंग से नहीं चुना गया था। डिफ़ॉल्ट रूप से, पहले perltidy उपयोगकर्ता को $HOME/.perltidyrc और फिर वैश्विक एक - /etc/perltidyrc । इस प्रकार, विन्यास को /etc में रखकर /etc हम इसे perlcritic-checker (आमतौर पर svn उपयोगकर्ता के तहत काम करने वाले) और perltidy प्रोग्राम दोनों के लिए उपलब्ध perltidy , कोई फर्क नहीं पड़ता कि उपयोगकर्ता इसे perltidy है।

अंत में, हमें बस प्रस्तुत करने के लिए निर्देश को सत्यापित करने के लिए perlcritic-checker.pl स्क्रिप्ट को कॉल करने की perlcritic-checker.pl है। जैसा कि आप अनुमान लगा सकते हैं, इसके लिए आपको pre-commit हुक को संपादित करने की आवश्यकता है:

 बिल्ली> $ SVN_REPO / हुक / पूर्व-प्रतिबद्ध << 'EOF'
 #! / बिन / श

 #
 # SVN पूर्व-प्रतिबद्ध हुक स्क्रिप्ट उदाहरण
 #

 REPOS = "$ 1"
 TXN = "$ 2"
 PREFIX = "/ usr / स्थानीय"

 # सुनिश्चित करें कि पर्ल कोड कोडिंग मानकों का पालन करता है
 $ PREFIX / bin / perlcritic-checker.pl \
     - भंडार "$ REPOS"
     --config "$ REPOS / हुक / perlcritic-checker.conf" \
     - रूपांतरण "$ TXN" ||  बाहर निकलें 1

 # सभी चेक पास हो गए हैं, इसलिए कमिट की अनुमति दें
 बाहर निकलें 0
 EOF
 chmod 755 $ SVN_REPO / हुक / पूर्व-वचन

यह सेटअप चरण को पूरा करता है। सब कुछ पहले प्रयोग के लिए तैयार है।

अच्छा, बुरा, प्रगतिशील

इसलिए, रिपॉजिटरी में टेस्ट प्रोजेक्ट के लिए एक फोल्डर बनाएं और वर्किंग कॉपी का चेकआउट करें:

 WORK_COPY = "/ tmp / test_project" निर्यात करें
 svn mkdir फ़ाइल: // $ SVN_REPO / test_project -m ""
 svn चेकआउट फ़ाइल: // $ SVN_REPO / test_project $ WORK_COPY

प्रयोग के लिए, हमें एक "अच्छी" फ़ाइल चाहिए (उल्लंघन के बिना फ़ाइल):

 बिल्ली> $ WORK_COPY / good_file.pl << 'EOF'
 #! / usr / बिन / पर्ल

 # ==================================================== ==============================
 # समीक्षा: $ Id $
 # विवरण: उल्लंघन के बिना फ़ाइल
 # ==================================================== ==============================

 सख्त का उपयोग करें;
 चेतावनी का उपयोग करें;

 हमारे $ संस्करण = '1.0';

 उप मुख्य {
     वापसी;
 }

 मुख्य ();
 EOF
 chmod 755 $ WORK_COPY / good_file.pl

और "खराब" फ़ाइल (उल्लंघन के साथ फ़ाइल):

 बिल्ली> $ WORK_COPY / bad_file.pl << 'EOF'
 #! / usr / बिन / पर्ल

 # ==================================================== ==============================
 # समीक्षा: $ Id $
 # विवरण: उल्लंघन के साथ फाइल
 # ==================================================== ==============================

 सख्त का उपयोग करें;

 # फ्यूज चेतावनियाँ;

 हमारे $ संस्करण = "1"।  "।"  ।  "0";

 उप मुख्य () {
     वापस आना;
 }

 मुख्य ();
 EOF
 chmod 755 $ WORK_COPY / bad_file.pl

समस्याओं के बिना एक अच्छी फ़ाइल कमिट पास होनी चाहिए:

 cd $ WORK_COPY
 svn जोड़ें good_file.pl
 svn प्रतिबद्ध -m "यह प्रतिबद्ध ठीक होना चाहिए" good_file.pl

लेकिन खराब फाइल करने पर आलोचना का कारण बनना चाहिए:

 cd $ WORK_COPY
 svn जोड़ें bad_file.pl
 svn कमिट-एम "यह कमिट फेल होना चाहिए" bad_file.pl

 Bad_file.pl जोड़ना
 फ़ाइल डेटा संचारित करना .svn: प्रतिबद्ध विफल (विवरण का पालन करें):
 svn: उत्पादन के साथ पूर्व-प्रतिबद्ध हुक (निकास कोड 1) द्वारा अवरुद्ध प्रतिबद्ध:
 test_project / bad_file.pl: [सबरूटींस :: प्रोहिबिटएक्सप्लिसिट रीटर्नउंडफ] लाइन 15, कॉलम 5 में स्पष्ट "अनडेफ" के साथ "रिटर्न" स्टेटमेंट (गंभीरता: 5)
 test_project / bad_file.pl: [Subroutines :: ProhibitSubroutinePrototypes] पंक्ति 14, कॉलम 1 में प्रयुक्त सबरूटीन प्रोटोटाइप (गंभीरता: 5)
 test_project / bad_file.pl: [टेस्टिंगअंडबेडिंग :: आवश्यकतावार्ता] कोड चेतावनी से पहले कोड 12, कॉलम 1 पर सक्षम हैं। (गंभीरता: 4)
 test_project / bad_file.pl: [ValuesAndExpressions :: ProhibitNoisyQuotes] पंक्ति 12, कॉलम 22 पर एक शोर स्ट्रिंग के साथ प्रयोग किया जाता है। (गंभीरता: 2)
 test_project / bad_file.pl: [ValuesAndExpressions :: ProhibitInterpolationOfLiterals] पंक्ति 12, कॉलम 16 में शाब्दिक स्ट्रिंग का अनावश्यक प्रक्षेप। (गंभीरता: 1)
 test_project / bad_file.pl: [ValuesAndExpressions :: ProhibitInterpolationOfLiterals] पंक्ति 12, कॉलम 22 पर शाब्दिक स्ट्रिंग का अनावश्यक प्रक्षेप। (गंभीरता: 1)
 test_project / bad_file.pl: [ValuesAndExpressions :: ProhibitInterpolationOfLiterals] लाइन 12, कॉलम 28 पर शाब्दिक स्ट्रिंग का अनावश्यक प्रक्षेप। (गंभीरता: 1)
 ---
 आप टिप्पणी संदेश की शुरुआत में 'कोई CRITIC' रखकर सभी जांचों को दरकिनार कर सकते हैं,
 जैसे: svn ci -m "NO CRITIC: आपातकालीन हॉटफ़िक्स" FooBar.pm

यह देखा जा सकता है कि उल्लंघन गंभीरता के अवरोही क्रम में क्रमबद्ध हैं, और विभिन्न रंगों में भी चित्रित किए गए हैं। यदि उल्लंघन फ़ाइल की एक विशिष्ट रेखा से संबंधित है, और उनमें से अधिकांश हैं, तो इस रेखा पर लाइन संख्या और स्थिति संख्या इंगित की जाती है। यदि पॉलिसी का सार और शीर्षक इसके सार को नहीं समझते हैं, तो आप इस तरह से विस्तारित सहायता प्राप्त कर सकते हैं: perlcritic --doc TestingAndDebugging::RequireUseWarnings | less perlcritic --doc TestingAndDebugging::RequireUseWarnings | less

मैं ध्यान देता हूं कि Perl::Critic के संस्करण पर निर्भर करता है Perl::Critic मॉड्यूल और स्थापित नीति की सूची, आउटपुट थोड़ा अलग हो सकता है (इस विसंगति की संभावना को कम करने के लिए, हमने विशेष रूप से perlcritic-brutal.conf में theme निर्देशन का उपयोग करके सक्रिय नीति की सूची को संकुचित कर दिया है)।

लेकिन हमारी खराब फ़ाइल पर वापस। तोड़फोड़ द्वारा हमारी प्रतिबद्धता को स्वीकार करने से इनकार कर दिया गया है, जाने के दो तरीके हैं। पहला तरीका (दाएं) उल्लंघन को खत्म करना और फिर से प्रयास करना है। दूसरा तरीका (मजबूर) है कि कमिटमेंट को इमरजेंसी के रूप में चिह्नित करें और इस तरह सभी जांच को दरकिनार कर दें। यहाँ यह कैसा दिखता है:

 cd $ WORK_COPY
 svn प्रतिबद्ध -m "NO CRITIC: मैं जल्दी में हूं और मुझे परवाह नहीं है" bad_file.pl

इस रूप में, कमिट की आलोचना नहीं की जाएगी और सेंसरशिप विभाग को दरकिनार कर रिपॉजिटरी में जाएगा।

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

 ## कोई आलोचक नहीं है (सबरूटीन्स :: निषेध

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

 ## आलोचक का उपयोग करें

मैं एक बार फिर से दो '#' पात्रों और इस तथ्य पर ध्यान आकर्षित करना चाहता हूं कि नीति को नाम से बंद कर दिया गया है, और सभी एक ही बार में चालू हो जाते हैं।

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

तो हम सबसे दिलचस्प - perlcritic-checker के संचालन के प्रगतिशील मोड के लिए मिला। इस सुविधा के बिना, बड़ी मौजूदा पर्ल परियोजनाओं के ढांचे में इस प्रणाली को लागू करना असंभव होगा। जैसा कि अभ्यास से पता चला है, पहले के गैर-राजनीतिक कोड (यहां तक ​​कि एक गैर-सख्त severity स्तर पर) में उल्लंघन की संख्या सिर्फ ऑफ स्केल है। कोड के शेर के हिस्से को संशोधित करना, इसके अलावा, काम कोड, केवल Perl::Critic आलोचना अक्षम है, और आपातकालीन आवागमन ( NO CRITIC ) के दुरुपयोग से इस प्रणाली का मूल्य शून्य हो जाएगा।

तो, कैसे perlcritic-checker प्रगतिशील मोड perlcritic-checker ? प्रगतिशील मोड में, प्रत्येक परिवर्तित फ़ाइल के लिए perlcritic-checker पहले उल्लंघन की सूची और अब उल्लंघन की सूची की तुलना करता है। दोनों उल्लंघनों की सूची नाम नीति द्वारा समूहीकृत की जाती है और घटना के काउंटर से सुसज्जित होती है। इसलिए, अगर वर्तमान प्रतिबद्ध में कम से कम एक उल्लंघन हुआ है जो फ़ाइल में जोड़े जाने से पहले नहीं हुआ है, तो पूरी प्रतिबद्ध को अस्वीकार कर दिया जाएगा, और एक रिपोर्ट उपयोगकर्ता को भेजी जाएगी, जो यह इंगित करेगा कि किस प्रकार के उल्लंघन जोड़े गए थे और किस मात्रा में। इस प्रकार, perlcritic-checker मौजूदा उल्लंघनों की ओर आंख मूंद perlcritic-checker , लेकिन नए लोगों के परिचय को प्रतिबंधित करता है।

मैं ध्यान देता हूं कि यह योजना नई जोड़ी गई फाइलों पर लागू नहीं होती है। पहली बार में, फ़ाइल की सख्त सख्त मोड में आलोचना की जाती है, जो आम तौर पर तार्किक है: पहले से मौजूद गैर-मौजूद फ़ाइल में, स्पष्ट रूप से कोई उल्लंघन नहीं था।

एक उदाहरण के साथ प्रदर्शित करें। जैसा कि हम याद करते हैं, इस तथ्य के बावजूद कि "खराब" फ़ाइल में उल्लंघन शामिल थे, हमने इसे NO CRITIC साथ प्रतिबद्ध करने पर जोर दिया। हम इस फ़ाइल में नए उल्लंघनों को जोड़ेंगे और मौजूदा लोगों में से एक को ठीक कर देंगे (और क्या शामिल use warnings लिए use warnings बदले use strict की अनुपस्थिति को perlcritic-checker देगा?):

 बिल्ली> $ WORK_COPY / bad_file.pl << 'EOF'
 #! / usr / बिन / पर्ल

 # ==================================================== ==============================
 # समीक्षा: $ Id $
 # विवरण: उल्लंघन के साथ फाइल (संस्करण 2)
 # ==================================================== ==============================

 # सख्त;
 चेतावनी का उपयोग करें;

 हमारे $ संस्करण = "1"।  "।"  ।  "0";

 उप फू () {
     1 + 1;
 }

 उप मुख्य () {
     वापस आना;
 }

 मुख्य ();
 EOF
 cd $ WORK_COPY
 svn प्रतिबद्ध -m "फ़ाइल में अधिक उल्लंघन जोड़ें" bad_file.pl

 बैड_फाइल.प्ले भेजना
 फ़ाइल डेटा संचारित करना .svn: प्रतिबद्ध विफल (विवरण का पालन करें):
 svn: उत्पादन के साथ पूर्व-प्रतिबद्ध हुक (निकास कोड 1) द्वारा अवरुद्ध प्रतिबद्ध:
 test_project / bad_file.pl: [सबरूटीन्स :: प्रोहिबिटएक्सप्लिसिट रीटर्नउंडफ] लाइन 18, कॉलम 5 में स्पष्ट "अनडेफ" के साथ "रिटर्न" स्टेटमेंट (गंभीरता: 5)
 test_project / bad_file.pl: [Subroutines :: ProhibitSubroutinePrototypes] Subroutine प्रोटोटाइप का उपयोग पंक्ति 13, कॉलम 1 में किया गया है (गंभीरता: 5)
 test_project / bad_file.pl: [Subroutines :: ProhibitSubroutinePrototypes] पंक्ति 17, कॉलम 1 में प्रयुक्त सबरूटीन प्रोटोटाइप (गंभीरता: 5)
 test_project / bad_file.pl: [TestAndDebugging :: आवश्यकताएँ उपयोग करें] कोड सख्त होने से पहले कोड 11 पंक्ति में सक्षम हैं, कॉलम 1 (गंभीरता: 5)
 test_project / bad_file.pl: [सबरूटीन्स :: आवश्यकताएँफर्टलाइन] सबरूटीन पंक्ति 13, कॉलम 1 में "वापसी" के साथ समाप्त नहीं होता है (गंभीरता: 4)
 test_project / bad_file.pl: [ValuesAndExpressions :: ProhibitNoisyQuotes] पंक्ति 11, स्तंभ 22 पर एक शोर स्ट्रिंग के साथ प्रयोग किया जाता है। (गंभीरता: 2)
 test_project / bad_file.pl: [ValuesAndExpressions :: ProhibitInterpolationOfLiterals] पंक्ति 11, कॉलम 16 में शाब्दिक स्ट्रिंग का अनावश्यक प्रक्षेप। (गंभीरता: 1)
 test_project / bad_file.pl: [ValuesAndExpressions :: ProhibitInterpolationOfLiterals] लाइन 11, कॉलम 22 पर शाब्दिक स्ट्रिंग का बेकार प्रक्षेप। (गंभीरता: 1)
 test_project / bad_file.pl: [ValuesAndExpressions :: ProhibitInterpolationOfLiterals] लाइन 11, कॉलम 28 पर शाब्दिक स्ट्रिंग का बेकार प्रक्षेप। (गंभीरता: 1)
 test_project / bad_file.pl: [Subroutines :: ProhibitSubroutinePrototypes] आपको इस प्रकार के कम से कम 1 उल्लंघन (ओं) को ठीक करना चाहिए (था: 1, अब: 2) (गंभीरता: 5)
 test_project / bad_file.pl: [TestAndDebugging :: आवश्यकताएँ उपयोग] आपको इस प्रकार के कम से कम 1 उल्लंघन (ओं) को ठीक करना चाहिए (था: 0, अब: 1) (गंभीरता: 5)
 test_project / bad_file.pl: [सबरूटीन्स :: आवश्यकताएँफर्टलाइन] आपको इस प्रकार के कम से कम 1 उल्लंघन (ओं) को ठीक करना चाहिए (था: 0, अब: 1) (गंभीरता: 4)
 ---
 आप टिप्पणी संदेश की शुरुआत में 'कोई CRITIC' रखकर सभी जांचों को दरकिनार कर सकते हैं,
 जैसे: svn ci -m "NO CRITIC: आपातकालीन हॉटफ़िक्स" FooBar.pm

जैसी कि उम्मीद थी, प्रतिबद्ध विफल हो गया। विषम पृष्ठभूमि द्वारा हाइलाइट की गई रिपोर्ट के नए अनुभाग पर ध्यान दें। इस खंड में, perlcritic-checker ने एक प्रकार का perlcritic-checker उल्लंघन दिखाया। विशेष रूप से, यह कहता है कि हमने [Subroutines::ProhibitSubroutinePrototypes] प्रकार का दूसरा उल्लंघन जोड़ा और दो नए उल्लंघनों को पेश किया, जो पहले फ़ाइल में बिल्कुल भी नहीं थे: [TestingAndDebugging::RequireUseStrict] और [Subroutines::RequireFinalReturn] । जैसा कि रिपोर्ट से किया गया है, उल्लंघन [TestingAndDebugging::RequireUseWarnings] हमने सही किया है कि अतिरिक्त भोग नहीं दिया जाता है, जिसकी उम्मीद की जानी चाहिए।

यहां पाठक पूछ सकता है: हमें रिपोर्ट के पहले भाग की आवश्यकता क्यों है, जो कि सभी उल्लंघनों को सूचीबद्ध करता है, यहां तक ​​कि उन लोगों के लिए भी जो प्रतिबद्ध थे? मुझे आपको याद दिलाना है कि उल्लंघन की सूचियों की तुलना पहले और अब नाम नीति और घटना के काउंटर द्वारा की जाती है। दूसरे शब्दों में, perlcritic-checker लाइन 13 और लाइन 17 पर [Subroutines::ProhibitSubroutinePrototypes] प्रकार का उल्लंघन नहीं करता है। इस मद में रिपोर्ट के "प्रगतिशील" भाग से गायब होने के लिए, उपयोगकर्ता उनमें से किसी को भी समाप्त कर सकता है। इस प्रकार, रिपोर्ट का ऊपरी भाग एक प्रकार की निर्देशिका के रूप में कार्य करता है जिसमें, नीति नाम से, आप उस पंक्ति संख्या को पा सकते हैं जिसमें इस नीति का उल्लंघन किया गया था।

अंत में, मैं कहूँगा कि NO CRITIC प्रगतिशील मोड में भी काम करती है, हालाँकि, इस सुविधा का दुरुपयोग अत्यधिक अनुशंसित नहीं है।

आगे की ट्यूनिंग के लिए टिप्स

1. आलोचक के साथ अपने संपादक के एकीकरण को अनुकूलित करें: VIM , Emacs ।
2. अपने संपादक एकीकरण को perltidy साथ कॉन्फ़िगर करें: VIM , Emacs ।
3. एक बचत बैंक में अपने पैसे रखें Perl::Critic संस्करण नियंत्रण के तहत Perl::Critic प्रोफाइल और हर प्रतिबद्ध के साथ सर्वर पर एक कार्यशील प्रति अपडेट करें। इसलिए आपकी टीम के सभी सदस्य एक ही प्रोफ़ाइल के साथ स्थानीय स्तर पर काम करेंगे, और perlcritic-checker अपने आप ही इसमें कोई बदलाव करेगा।
4. सबसे सख्त प्रोफ़ाइल ( severity = brutal , सभी नीतियों को शामिल किया गया है) के साथ शुरू करें और आवश्यकतानुसार अपवाद और समायोजन जोड़ें।
5. अपने संपादक में *.pm , *.pl और *.t फ़ाइलों के लिए टेम्प्लेट को संशोधित करें ताकि वे प्रारंभ में आलोचक के दृष्टिकोण से सही हों।
6. पर्ल बेस्ट प्रैक्टिसेज पढ़ने का समय निकालें।

निष्कर्ष

Perl::Critic परिचय देते समय Perl::Critic अपनी उत्पादन प्रक्रिया में Perl::Critic करना, यह समझना महत्वपूर्ण है कि चीजों को क्रम में रखने के लिए यह एक सुविधाजनक उपकरण है, न कि हठधर्मिता, जिसके सभी नियमों का आँख बंद करके पालन किया जाना चाहिए। इस स्थिति से अनुमोदन करते हुए, आपकी टीम अंततः कॉन्फ़िगरेशन में आ जाएगी जो आपकी आवश्यकताओं, आपकी परियोजना और आपकी आदतों के लिए पूरी तरह से उपयुक्त है।

संदर्भ

• पर्ल :: समालोचक
• टेस्ट :: पर्ल :: समालोचक
• टेस्ट :: पर्ल :: आलोचना :: प्रगतिशील
• VIM के लिए Perl-support.vim प्लगइन (perlcritic, perltidy और कई अन्य उपहारों के साथ एकीकरण)
• Emacs Perlcritic के साथ एकीकरण
• Emacs एकीकरण perltidy के साथ
• google कोड पर perlcritic-checker
• CPAN पर perlcritic-checker
• धीरे-धीरे टेस्ट के साथ कोडिंग मानकों को लागू करें :: पर्ल :: आलोचना :: प्रगतिशील
• इस आलेख से फ़ाइलों और कॉन्फ़िगरेशन का परीक्षण करें