प्रतिबद्ध पर PHP कोड का स्वचालित सत्यापन

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

रविवार, 3:40 बजे

इस शुरुआती समय में, काम पर बैठे और चाय के लिए एक ब्रेक ले रहे थे, मैंने सोचा, कल आपको ऑफिस जाने की ज़रूरत है और कोड की जाँच के लिए सुबह 2 - 3 घंटे फिर से खर्च करने होंगे, फिर अन्य 5 घंटे काम करने के लिए, कुल 5 घंटे के लिए, फिर शायद काम करना 2 घंटे और घर चलाओ। और निश्चित रूप से, मैं उन कार्यों को हल नहीं कर सकता, जो मैंने शेष 2 - 3 घंटे के लिए निर्धारित किए हैं, और इन समस्याओं को हल करने के दौरान, मैं अपने परिवार को नष्ट कर सकता हूं, आदि। यह नहीं चल सकता। सबसे पहले, मैं एक प्रोग्रामर हूं, न कि "सेर्बस" और मुझे सत्यापन प्रक्रिया को स्वचालित करने की आवश्यकता है, अगर यह पूरे सत्यापन समय को नहीं हटाता है, तो कम से कम इसे कम करें।
मैं पहिया को फिर से जोड़ना पसंद नहीं करता, इसलिए मैंने तुरंत खोज इंजन की ओर रुख किया और पूछा: "मानकों की जाँच करना PHP", शीर्ष दस परिणामों को देखते हुए, मैंने अक्सर होने वाले नाम " PHP_Codesniffer " पर ध्यान दिया और उसी नाम से पूछा - मैंने देखा कि यह स्वचालित कोड शैली की जाँच के लिए PEAR लाइब्रेरी थी। , जैसा कि वे कहते हैं - "डॉक्टर ने क्या निर्धारित किया है!" और डेवलपर्स की विश्वसनीयता में कोई संदेह नहीं है कि यह संभावित वैश्विक कार्यान्वयन के साथ एक लाभकारी प्रभाव होगा। सर्वर पर लाइब्रेरी स्थापित करने के बाद:

pear install PHP_CodeSniffer-1.3.0RC1

यह माना जाता है कि आपके पास सर्वर पर PEAR वितरण स्थापित है। स्थापना के बाद, नई phpcs सेवा उपलब्ध होगी:

phpcs --standard=Zend your.php

थोड़ा खेलने के बाद, मुझे खुशी हुई कि यह समाधान पहले से ही कई मानकों का समर्थन करता है: स्क्विज़, मायसोर्स, PHPCS, Zend, PEAR। यह मेरे अनुकूल है, जैसा कि हमने नियत समय में अनुमोदित किया है कि हम Zend मानक के अनुसार कोड करेंगे।
इस पुस्तकालय को तेज करने के बारे में आधिकारिक दस्तावेज में पाया जा सकता है ।

रविवार 4:00 बजे

अपने खोज और इसके त्वरित "उदय" से प्रेरित होकर, सपना फिर से शुरू हुआ। पहले कार्य हल किया गया था, अब इस समाधान को कमिट के दौरान संस्करण नियंत्रण से जोड़ना बाकी है। PHP_CodeSniffer के लिए प्रलेखन में SVN के साथ एकीकरण के विवरण के लिए समर्पित एक खंड है - यह अच्छा था, क्योंकि हम SVN का उपयोग करना पसंद करते हैं, लेकिन मैं GIT का उपयोग करता हूं और गिट के लिए अपना हुक लिखने का फैसला किया और यहां मुझे लगता है: "मुझे विश्वास नहीं है कि PEAR समाधान पर एकीकरण विवरण नहीं है जीआईटी के साथ। ” और फिर से, खोज इंजन की ओर मुड़ते हुए, मुझे तैयार किए गए समाधान phpcs- पूर्व-कमिट मिले :

git clone https://github.com/s0enke/git-hooks.git

इस हुक को एकीकृत करने के लिए, आपको प्री-कमिट फ़ाइल को अपने गिट रिपॉजिटरी (.git / हुक) के हुक फ़ोल्डर में डालने की आवश्यकता है। गिट हुक में कौन रुचि रखता था, इस विषय में एक है।
और प्रतिबद्ध की आखिरी जांच, मुझे शैली का पालन नहीं करने की त्रुटियों के विवरण के साथ एक तालिका मिली। मैं इस बात का उदाहरण नहीं दूंगा कि phpcs त्रुटि तालिका कैसे प्रदर्शित होती है और क्यों। .It / हुक / पूर्व-प्रतिबद्ध में आपको यह निर्दिष्ट करने की आवश्यकता है कि आप किस शैली का उपयोग करना चाहते हैं:

PHPCS_CODING_STANDARD=Zend

चेक किए जाने वाले फ़ाइल एक्सटेंशन भी इंगित करें:

PHPCS_FILE_PATTERN="\.(php|phtml)$"

यदि आपको कमिट करते समय कोई त्रुटि मिलती है:
error: cannot run .git/hooks/pre-commit: No such file or directory
इसका मतलब है कि बैश करने का रास्ता सही नहीं है, इसे .it / हुक / प्री-कमिट में बदल दें

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

सोमवार, 17:00 बजे

सामान्य तौर पर, सब कुछ ठीक था, लेकिन जिस परियोजना पर मैंने परीक्षण करने का फैसला किया वह बहुत प्राचीन था और यह कुछ मानकों को Zend मानक पर लाने के लिए लाभहीन था, उदाहरण के लिए, चर की ऊंट शैली। और मुझे PHP_Codesniffer के लिए अपना खुद का मानक बनाना था। शैली की जाँच विवरण स्वयं में निहित हैं:

PEAR_PATH/PHP/CodeSniffer/Standards/

PEAR_PATH हमारे सर्वर पर PEAR पुस्तकालयों के साथ फ़ोल्डर का मार्ग है, वे / usr / स्थानीय / शेयर / नाशपाती / में स्थित हैं।

अपनी खुद की शैली बनाने के लिए, PEAR_PATH / PHP / CodeSniffer / Standard / में अपने_सहाय फ़ोल्डर बनाएँ।

अपने स्टाइल पैक में, ruleset.xml बनाएं। आप इस फ़ाइल के प्रारूप के बारे में यहाँ पढ़ सकते हैं, मैं केवल वही बताऊंगा जो मेरे काम आया।
इस तथ्य के कारण कि एन्कोडिंग आवश्यकताओं को Zend शैली के जितना संभव हो उतना करीब है, मैंने बस PEAR_PATH / PHP / CodeSniffer / Standard / Zend / ruleset.xml से सामग्री की प्रतिलिपि बनाई:

<?xml version= "1.0" ?>
<ruleset name= "Zend" >
<description>A coding standard based on an early Zend Framework coding standard. Note that this standard is out of date.</description>

<!-- Include some sniffs from all around the place -->
<rule ref = "Generic.Functions.FunctionCallArgumentSpacing" />
<rule ref = "Generic.Functions.OpeningFunctionBraceBsdAllman" />
<rule ref = "Generic.PHP.DisallowShortOpenTag" />
<rule ref = "Generic.WhiteSpace.DisallowTabIndent" />
<rule ref = "PEAR.Classes.ClassDeclaration" />
<rule ref = "PEAR.ControlStructures.ControlSignature" />
<rule ref = "PEAR.Functions.FunctionCallSignature" />
<rule ref = "PEAR.Functions.ValidDefaultValue" />
<rule ref = "PEAR.WhiteSpace.ScopeClosingBrace" />
<rule ref = "Squiz.Functions.GlobalFunction" />

<!-- Lines can be 80 chars long , show errors at 120 chars -->
<rule ref = "Generic.Files.LineLength" >
<properties>
<property name= "lineLimit" value = "120" />
<property name= "absoluteLineLimit" value = "140" />
</properties>
</rule>

<!-- Use Unix newlines -->
<rule ref = "Generic.Files.LineEndings" >
<properties>
<property name= "eolChar" value = "\n" />
</properties>
</rule>
</ruleset>


नियमों के टैग में, अपने नाम को अपने नाम के साथ बदलें और Zend के साथ एक नियम जोड़ें:

<rule ref = "Zend.Debug.CodeAnalyzer" />


ऊंट-शैली को अक्षम करने के लिए, मैं प्रतिलिपि बनाता हूं:
PEAR_PATH / PHP / CodeSniffer / Standards / Zend / Sniffs / NamingConventions / ValidVariableNameSniff.php PEAR_PATH / PHP / CodeSniffer / मानकों / your_STYLE / Sniff / NamingConventions / ValidVariableName नाम में। Zend_Sniffs_NamingConventions_ValidVariableNameSniff से वर्ग का नाम बदलकर Your_STYLE_Sniffs_NamingConventions_ValidVariableNameSniff जोड़ा गया:

public $isCheckCamelCaps;


और उन्होंने हर जगह इस "ध्वज" के लिए एक चेक जोड़ा। अब अगर आपको इसे फिर से परिभाषित करने की आवश्यकता है - तो इसे ruleset.xml से किया जा सकता है:

<rule ref = "YOUR_STYLE.NamingConventions.ValidVariableName" >
<properties>
<property name= "isCheckCamelCaps" value = "1" />
</properties>
</rule>


मंगलवार, 19:00 बजे

बहुत सी चीजें सामने आईं, जिसके लिए उनकी आंखें बंद थीं, लेकिन समय आ गया है कि उन्हें क्रम में रखा जाए! कोड शैली की सबसे उपयोगी जांच कोड की रेखा की लंबाई के लिए जाँच कर रही थी, और इसके लिए धन्यवाद, कई अपठनीय स्थानों को नवीनीकृत किया गया था।
सच है, मुझे रूसी टिप्पणियों के साथ एक समस्या का सामना करना पड़ा, पूरे कोड को यूटीएफ -8 में संग्रहीत किया गया है, और कोडस्निफर मानक स्ट्रिंग के साथ स्ट्रिंग की लंबाई की जांच करता है और यह तर्कसंगत है कि लाइनें दोगुनी थीं। मैंने क्लास ओवरराइड्स से परेशान नहीं किया, जो कि अधिक सही होगा, लेकिन सिर्फ PEAR_PATH / PHP / CodeSniffer / Standard / Generic / Sniffs / Files / LineLengthSniff.php में जोड़ा गया:

public $charset = 'UTF-8' ;


और इसके साथ बदल दिया गया है:

mb_strlen($lineContent, $ this ->charset)


शनिवार

यह CodeSniffer के साथ एक आसान सप्ताह नहीं था, और यहाँ पेशेवरों हैं:

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

विपक्ष:

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