Perl Language
सर्वोत्तम प्रथाएं

पर्ल का उपयोग करना :: समालोचक

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

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

आप Perl :: Critic को अपने ब्राउज़र के माध्यम से perlcritic.com पर आज़मा सकते हैं ।

स्थापना

cpan Perl::Critic

यह बुनियादी नियम और एक लंबवत स्क्रिप्ट स्थापित करेगा जिसे कमांड लाइन से बुलाया जा सकता है।

मूल उपयोग

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

 perlcritic -1 /path/to/script.pl

perlcritic स्क्रिप्ट और मॉड्यूल पर दोनों काम करता है। -1 उन नियमों के गंभीरता स्तर को संदर्भित करता है जिन्हें आप स्क्रिप्ट के खिलाफ चलाना चाहते हैं। पांच स्तर हैं जो कि कितने पर्ल के अनुरूप हैं :: आलोचक आपके कोड को अलग करेगा।

-5 सबसे कोमल है और केवल संभावित खतरनाक समस्याओं के बारे में चेतावनी देगा जो अप्रत्याशित परिणाम पैदा कर सकता है। -1 सबसे क्रूर है और चीजों के बारे में शिकायत करेगा कि आपका कोड छोटा है या नहीं। मेरे अनुभव में, लेवल 3 के अनुरूप कोड रखना बहुत अच्छा है ताकि खतरे से बाहर न रहे।

डिफ़ॉल्ट रूप से, कोई भी विफलता कारण और गंभीरता को सूचीबद्ध करेगी जो नियम को ट्रिगर करता है:

perlcritic -3 --verbose 8 /path/to/script.pl

Debugging module loaded at line 16, column 1.  You've loaded Data::Dumper, which probably shouln't be loaded in production.  (Severity: 4)
Private subroutine/method '_sub_name' declared but not used at line 58, column 1.  Eliminate dead code.  (Severity: 3)
Backtick operator used at line 230, column 37.  Use IPC::Open3 instead.  (Severity: 3)
Backtick operator used at line 327, column 22.  Use IPC::Open3 instead.  (Severity: 3)

देखने की नीतियाँ

आप जल्दी से देख सकते हैं कि कौन से नियमों को ट्रिगर किया जा रहा है और क्यों perlcritic के --verbose विकल्प का उपयोग करके:

स्तर को 8 पर सेट करना आपको वह नियम दिखाएगा जिसने चेतावनी जारी की है:

perlcritic -3 --verbose 8 /path/to/script.pl

[Bangs::ProhibitDebuggingModules] Debugging module loaded at line 16, column 1.  (Severity: 4)
[Subroutines::ProhibitUnusedPrivateSubroutines] Private subroutine/method '_sub_name' declared but not used at line 58, column 1.  (Severity: 3)
[InputOutput::ProhibitBacktickOperators] Backtick operator used at line 230, column 37.  (Severity: 3)
[InputOutput::ProhibitBacktickOperators] Backtick operator used at line 327, column 22.  (Severity: 3)

जबकि 11 का स्तर विशिष्ट कारण बताएगा कि नियम क्यों मौजूद है:

perlcritic -3 --verbose 11 /path/to/script.pl

Debugging module loaded at line 16, near 'use Data::Dumper;'.
  Bangs::ProhibitDebuggingModules (Severity: 4)
    This policy prohibits loading common debugging modules like the
    Data::Dumper manpage.

    While such modules are incredibly useful during development and
    debugging, they should probably not be loaded in production use. If this
    policy is violated, it probably means you forgot to remove a `use
    Data::Dumper;' line that you had added when you were debugging.
Private subroutine/method '_svn_revisions_differ' declared but not used at line 58, near 'sub _sub_name {'.
  Subroutines::ProhibitUnusedPrivateSubroutines (Severity: 3)
    By convention Perl authors (like authors in many other languages)
    indicate private methods and variables by inserting a leading underscore
    before the identifier. This policy catches such subroutines which are
    not used in the file which declares them.

    This module defines a 'use' of a subroutine as a subroutine or method
    call to it (other than from inside the subroutine itself), a reference
    to it (i.e. `my $foo = \&_foo'), a `goto' to it outside the subroutine
    itself (i.e. `goto &_foo'), or the use of the subroutine's name as an
    even-numbered argument to `use overload'.
Backtick operator used at line 230, near 'my $filesystem_diff = join q{}, `diff $trunk_checkout $staging_checkout`;'.
  InputOutput::ProhibitBacktickOperators (Severity: 3)
    Backticks are super-convenient, especially for CGI programs, but I find
    that they make a lot of noise by filling up STDERR with messages when
    they fail. I think its better to use IPC::Open3 to trap all the output
    and let the application decide what to do with it.

        use IPC::Open3 'open3';
        $SIG{CHLD} = 'IGNORE';

        @output = `some_command`;                      #not ok

        my ($writer, $reader, $err);
        open3($writer, $reader, $err, 'some_command'); #ok;
        @output = <$reader>;  #Output here
        @errors = <$err>;     #Errors here, instead of the console
Backtick operator used at line 327, near 'my $output = `$cmd`;'.
  InputOutput::ProhibitBacktickOperators (Severity: 3)
    Backticks are super-convenient, especially for CGI programs, but I find
    that they make a lot of noise by filling up STDERR with messages when
    they fail. I think its better to use IPC::Open3 to trap all the output
    and let the application decide what to do with it.

        use IPC::Open3 'open3';
        $SIG{CHLD} = 'IGNORE';

        @output = `some_command`;                      #not ok

        my ($writer, $reader, $err);
        open3($writer, $reader, $err, 'some_command'); #ok;
        @output = <$reader>;  #Output here
        @errors = <$err>;     #Errors here, instead of the console

कोड को अनदेखा करना

ऐसे समय होंगे जब आप एक पर्ल :: आलोचना नीति का अनुपालन नहीं कर सकते हैं। उन मामलों में, आप विशेष टिप्पणियों को लपेट सकते हैं, " ## आलोचक () और" ## कोई आलोचक नहीं ", अपने कोड के आसपास पर्ल बनाने के लिए :: आलोचक उनकी उपेक्षा करें। केवल उन नियमों को जोड़ें जिन्हें आप कोष्ठकों में अनदेखा करना चाहते हैं (गुणकों को अल्पविराम द्वारा अलग किया जा सकता है)।

##no critic qw(InputOutput::ProhibitBacktickOperator)
my $filesystem_diff = join q{}, `diff $trunk_checkout $staging_checkout`;
## use critic

पूरे कोड ब्लॉक को लपेटना सुनिश्चित करें या आलोचक अनदेखी बयान को पहचान नहीं सकता है।

## no critic (Subroutines::ProhibitExcessComplexity)
sub no_time_to_refactor_this {
    ...
}
## use critic

ध्यान दें कि कुछ नीतियाँ हैं जो दस्तावेज़ स्तर पर चलाई जाती हैं और उन्हें इस तरह से छूट नहीं दी जा सकती है। हालांकि, उन्हें बंद किया जा सकता है ...

स्थायी अपवाद बनाना

## कोई आलोचक () का उपयोग करना अच्छा नहीं है, लेकिन जैसा कि आप कोडिंग मानकों को अपनाना शुरू करते हैं, आप निश्चित रूप से कुछ नियमों के लिए स्थायी अपवाद बनाना चाहेंगे। आप .perlcriticrc कॉन्फ़िगरेशन फ़ाइल बनाकर ऐसा कर सकते हैं।

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

perlcritic -1 --profile=/path/to/.perlcriticrc /path/to/script.pl

फिर से, लंबित CPAN पृष्ठ में इन विकल्पों की पूरी सूची है। मैं अपनी स्वयं की कॉन्फ़िगर फ़ाइल से कुछ उदाहरण सूचीबद्ध करूंगा:

मूल सेटिंग्स लागू करें:

#very very harsh
severity = 1
color-severity-medium = bold yellow
color-severity-low = yellow
color-severity-lowest = bold blue

एक नियम को अक्षम करें (पॉलिसी के नाम के सामने डैश पर ध्यान दें):

# do not require version control numbers
[-Miscellanea::RequireRcsKeywords]

# pod spelling is too over-zealous, disabling
[-Documentation::PodSpelling]

एक नियम को संशोधित करना:

# do not require checking for print failure ( false positives for printing to stdout, not filehandle )
[InputOutput::RequireCheckedSyscalls]
    functions = open close

# Allow specific unused subroutines for moose builders
[Subroutines::ProhibitUnusedPrivateSubroutines]
private_name_regex = _(?!build_)\w+

निष्कर्ष

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