12 से अधिक वर्षों के लिए किया गया है। हमारे पास बहुत सारे PHP कोड (लाखों लाइनें) हैं और शायद 12 साल पहले लिखी गई लाइनें भी संरक्षित थीं। हमारे पास PHP 4 और PHP 5 के दिनों में वापस लिखे गए कोड हैं। हम दिन में दो बार कोड अपलोड करते हैं, और प्रत्येक लेआउट में लगभग 10-20 कार्य होते हैं। इसके अलावा, प्रोग्रामर तत्काल पैच - छोटे परिवर्तन पोस्ट कर सकते हैं। और इस तरह के पैच के दिन, हम कुछ दर्जन हासिल करते हैं। सामान्य तौर पर, हमारा कोड बहुत सक्रिय रूप से बदल रहा है।

हम विकास में तेजी लाने के लिए, और कोड की गुणवत्ता में सुधार करने के अवसरों की तलाश कर रहे हैं। इसलिए एक दिन हमने स्थैतिक कोड विश्लेषण को लागू करने का फैसला किया। यह क्या आया, कटौती के तहत पढ़ा।

सख्त प्रकार: हम अभी तक इसका उपयोग क्यों नहीं कर रहे हैं

एक बार, हमारे कॉर्पोरेट PHP चैट में एक चर्चा शुरू हुई। नए कर्मचारियों में से एक ने बताया कि कैसे काम के पिछले स्थान पर उन्होंने पूरे कोड के लिए अनिवार्य सख्त_टाइप + स्केलर टाइप संकेत पेश किए - और इससे उत्पादन पर कीड़े की संख्या में काफी कमी आई।

अधिकांश चैट पुराने समय के लोग इस तरह के नवाचार के खिलाफ थे। मुख्य कारण यह था कि PHP में एक कंपाइलर नहीं होता है जो कोड के सभी प्रकारों का संकलन समय पर करता है, और यदि आपके पास परीक्षणों के साथ कोड का 100% कवरेज नहीं है, तो हमेशा एक जोखिम होता है कि त्रुटियां उत्पादन पर पॉप अप होंगी, जो हम नहीं करते हैं। अनुमति देना चाहते हैं।

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

लेकिन एक निश्चित प्रणाली होने का विचार जहां कोड में एक प्रकार का बेमेल है, हमें पसंद आया। हमने सख्त_टाइप्स के विकल्पों के बारे में सोचा।

पहले तो हम भी PHP पैच करना चाहते थे। हम चाहते थे कि यदि फ़ंक्शन किसी प्रकार का स्केलर टाइप (int int) कहे, और दूसरा स्केलर टाइप (जैसे फ्लोट) आता है, तो TypeError (जो अपने आप में एक अपवाद है) को फेंका नहीं जाएगा, लेकिन एक प्रकार का रूपांतरण होगा, यदि साथ ही इस घटना को error.log में लॉग कर रहा है। यह हमें उन सभी स्थानों को खोजने की अनुमति देगा जहां प्रकारों के बारे में हमारी धारणा गलत है। लेकिन इस तरह के एक पैच हमारे लिए जोखिम भरा लग रहा था, और यहां तक कि बाहरी निर्भरता के साथ समस्याएं भी हो सकती हैं, इस तरह के व्यवहार के लिए तैयार नहीं।

हमने PHP को पैच करने के विचार को छोड़ दिया, लेकिन समय के साथ यह सब फ़ान स्टैटिक विश्लेषक की पहली रिलीज़ के साथ मेल खाता है, जिसमें पहला कमिटमेंट खुद रासमस लेरडोर्फ ने किया था। इसलिए हम स्टैटिक कोड एनालिसिस करने की कोशिश कर रहे हैं।

स्थिर कोड विश्लेषण क्या है?

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

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

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

हालांकि सब कुछ नहीं है कि हम जो analyzers पर विचार कर रहे हैं वह ठीक एक गलती है। गलती से, मेरा मतलब है कि कोड जो उत्पादन पर बना देगा। बहुत बार, जो विश्लेषणकर्ता पाते हैं वह अधिक अशुद्धि की संभावना है। उदाहरण के लिए, PHPDoc में एक गलत पैरामीटर प्रकार निर्दिष्ट किया जा सकता है। यह अशुद्धि कोड के संचालन को प्रभावित नहीं करती है, लेकिन बाद में कोड विकसित होगा - एक और प्रोग्रामर गलती कर सकता है।

मौजूदा PHP कोड एनालाइज़र

तीन लोकप्रिय PHP कोड विश्लेषक हैं:

और एक्जाकैट है , जिसे हमने आजमाया नहीं है।

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

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

हमने तीनों विश्लेषणों को लागू और उपयोग किया है। प्रत्येक की अपनी बारीकियाँ हैं, अपने बग हैं। लेकिन एक ही समय में तीन विश्लेषणकर्ताओं का उपयोग यह समझने की सुविधा देता है कि वास्तविक समस्या कहां है और गलत सकारात्मक कहां है।

विश्लेषक क्या कर सकते हैं

एनालाइज़र में कई सामान्य विशेषताएं होती हैं, इसलिए पहले हम देखते हैं कि वे सभी क्या कर सकते हैं, और फिर उनमें से प्रत्येक की सुविधाओं पर आगे बढ़ें।

मानक जाँच

बेशक, विश्लेषक इस तथ्य के लिए सभी मानक कोड जांच करते हैं:

कोड में सिंटैक्स त्रुटियां नहीं हैं;
सभी वर्गों, विधियों, कार्यों, स्थिरांक मौजूद हैं;
चर मौजूद हैं;
PHPDoc में, संकेत सही हैं।

इसके अलावा, पार्स अप्रयुक्त तर्कों और चर के लिए कोड की जांच करते हैं। इन त्रुटियों में से कई कोड में वास्तविक वसा की ओर ले जाती हैं।

पहली नज़र में, ऐसा लग सकता है कि अच्छे प्रोग्रामर ऐसी गलतियाँ नहीं करते हैं, लेकिन कभी-कभी हम जल्दी में होते हैं, कभी-कभी कॉपी-पेस्ट करते हैं, कभी-कभी हम बस असावधान होते हैं। और ऐसे मामलों में, ये चेक बहुत बचत करते हैं।

डेटा प्रकार की जाँच

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

मानक जांच के अलावा, विश्लेषकों को अभी भी बहुत कुछ करना है।

संघ के प्रकार

सभी विश्लेषक यूनियन प्रकार की अवधारणा का समर्थन करते हैं। मान लीजिए कि आपके पास एक फ़ंक्शन है:

/** * @var string|int|bool $yes_or_no */ function isYes($yes_or_no) :bool {    if (\is_bool($yes_or_no)) {         return $yes_or_no;     } elseif (is_numeric($yes_or_no)) {         return $yes_or_no > 0;     } else {         return strtoupper($yes_or_no) == 'YES';     } }

इसकी सामग्री बहुत महत्वपूर्ण नहीं है - इनपुट पैरामीटर string|int|bool का प्रकार string|int|bool महत्वपूर्ण है। यही है, $yes_or_no चर या तो एक स्ट्रिंग, पूर्णांक, या Boolean ।

PHP का उपयोग करते हुए, इस प्रकार के फ़ंक्शन पैरामीटर का वर्णन नहीं किया जा सकता है। लेकिन PHPDoc में, यह संभव है, और कई संपादक (जैसे PHPStorm) इसे समझते हैं।

स्थैतिक विश्लेषक में, इस प्रकार को संघ प्रकार कहा जाता है, और वे ऐसे डेटा प्रकारों की जांच करने में बहुत अच्छे हैं। उदाहरण के लिए, यदि हमने उपरोक्त फ़ंक्शन को इस तरह लिखा है ( Boolean जाँच के बिना):

 /** * @var string|int|bool $yes_or_no */ function isYes($yes_or_no) :bool {    if (is_numeric($yes_or_no)) {        return $yes_or_no > 0;    } else {        return strtoupper($yes_or_no) == 'YES';    } }

विश्लेषक यह देखेंगे कि या तो एक स्ट्रिंग या बूलियन स्ट्रैपर में आ सकता है, और एक त्रुटि लौटा सकता है - आप स्टूलपर को बूलियन पास नहीं कर सकते।

जब कोई फ़ंक्शन डेटा वापस नहीं कर सकता है तो इस प्रकार का चेक प्रोग्रामर को त्रुटियों या स्थितियों को सही ढंग से संभालने में मदद करता है। हम अक्सर ऐसे कार्य लिखते हैं जो कुछ डेटा या null लौटा सकते हैं:

 // load()  null   \User $User = UserLoader::load($user_id); $User->getName();

इस तरह के कोड के मामले में, विश्लेषक आपको बताएगा कि यहां $User चर null हो सकता है और यह कोड घातक हो सकता है।

गलत टाइप करें

PHP भाषा में ही, कुछ कार्य ऐसे हैं जो कुछ मान या असत्य वापस कर सकते हैं। यदि हम इस तरह के फ़ंक्शन को लिखते हैं, तो हम इसके प्रकार का दस्तावेजीकरण कैसे करेंगे?

          /** @return resource|bool */ function fopen(...) {       … }

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

 $fp = fopen('some.file','r'); if($fp === false) {     return false; } fwrite($fp, "some string");

एनालाइज़र शिकायत करते हैं कि fwrite पहले पैरामीटर संसाधन को स्वीकार करता है, और हम bool पास bool (क्योंकि विश्लेषक देखता है कि एक सच्चा विकल्प संभव है)। इस कारण से, सभी विश्लेषक इस तरह के "कृत्रिम" डेटा प्रकार को false समझते हैं, और हमारे उदाहरण में हम @return false|resource लिख सकते हैं। @return false|resource PHPStorm भी इस प्रकार के विवरण को समझता है।

सरणी आकार

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

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

विश्लेषक आपको ऐसी संरचनाओं का विवरण दर्ज करने की अनुमति देते हैं:

 /** @param array{scheme:string,host:string,path:string} $parsed_url */ function showUrl(array $parsed_url) { … }

इस उदाहरण में, हमने तीन स्ट्रिंग फ़ील्ड: scheme, host और path साथ एक सरणी का वर्णन किया। यदि फ़ंक्शन के अंदर हम दूसरे क्षेत्र में जाते हैं, तो विश्लेषक एक त्रुटि दिखाएगा।

यदि आप प्रकारों का वर्णन नहीं करते हैं, तो विश्लेषक सरणी की संरचना को "अनुमान" करने की कोशिश करेंगे, लेकिन, जैसा कि अभ्यास से पता चलता है, वे वास्तव में हमारे कोड के साथ सफल नहीं होते हैं। :)

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

सरणी कुंजी प्रकारों का वर्णन

PHP में, सरणी कुंजियाँ पूर्णांक और तार हो सकती हैं। प्रकार कभी-कभी स्थैतिक विश्लेषण (और प्रोग्रामर के लिए भी) के लिए महत्वपूर्ण हो सकते हैं। स्टेटिक विश्लेषक आपको PHPDoc में सरणी कुंजियों का वर्णन करने की अनुमति देते हैं:

 /** @var array<int, \User> $users */ $users = UserLoaders::loadUsers($user_ids);

इस उदाहरण में, PHPDoc का उपयोग करते हुए, हमने एक संकेत दिया कि $users सरणी कुंजियाँ पूर्णांक इन्टस हैं, और मान \User वर्ग के ऑब्जेक्ट हैं। हम टाइप कर सकते हैं \ उपयोगकर्ता [] के रूप में। यह विश्लेषक को बताएगा कि सरणी में \User वर्ग में ऑब्जेक्ट हैं, लेकिन हमें कुंजियों के प्रकार के बारे में कुछ भी नहीं बताएगा।

PHPStorm, संस्करण 2018.3 से शुरू होने वाले सरणियों के वर्णन के लिए इस प्रारूप का समर्थन करता है।

PHPDoc में आपका नाम स्थान

PHPStorm (और अन्य संपादक) और स्थिर विश्लेषक PHPDoc को अलग तरह से समझ सकते हैं। उदाहरण के लिए, विश्लेषक इस प्रारूप का समर्थन करते हैं:

 /** @param array{scheme:string,host:string,path:string} $parsed_url */ function showUrl($parsed_url) { … }

लेकिन PHPStorm उसे नहीं समझता। लेकिन हम इस तरह लिख सकते हैं:

 /** * @param array $parsed_url * @phan-param array{scheme:string,host:string,path:string} $parsed_url * @psalm-param array{scheme:string,host:string,path:string} $parsed_url */ function showUrl($parsed_url) { … }

इस मामले में, दोनों विश्लेषक और PHPStorm संतुष्ट होंगे। PHPStorm @param का उपयोग करेगा, और विश्लेषक अपने स्वयं के PHPDoc टैग का उपयोग करेंगे।

PHP सुविधाएँ जाँच

इस प्रकार का परीक्षण उदाहरण द्वारा सर्वोत्तम रूप से चित्रित किया गया है।

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

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

PHP में ऐसी कुछ विशेषताएं हैं। विश्लेषक धीरे-धीरे उपयुक्त चेक जोड़ते हैं या उन्हें सुधारते हैं, और हम, प्रोग्रामर, अब इन सभी विशेषताओं को याद रखने की आवश्यकता नहीं है।

हम विशिष्ट विश्लेषणकर्ताओं के विवरण की ओर मुड़ते हैं।

PHPStan

चेक गणराज्य से एक निश्चित Ondřej Mirtes का विकास। 2016 के अंत से सक्रिय रूप से विकसित।

PHPStan का उपयोग शुरू करने के लिए, आपको चाहिए:

इसे स्थापित करें (ऐसा करने का सबसे आसान तरीका संगीतकार के माध्यम से है)।
(वैकल्पिक) कॉन्फ़िगर करें।
सबसे सरल मामले में, बस चलाएं:

vendor/bin/phpstan analyse ./src

( src बजाय विशिष्ट फ़ाइलों की एक सूची हो सकती है जिन्हें आप जांचना चाहते हैं)।

PHPStan स्थानांतरित फ़ाइलों से PHP कोड पढ़ेगा। यदि वह अज्ञात वर्गों का सामना करता है, तो वह उन्हें अपने इंटरफ़ेस को समझने के लिए ऑटोलैड के साथ और प्रतिबिंब के माध्यम से लोड करने का प्रयास करेगा। आप Bootstrap फ़ाइल में पथ को स्थानांतरित कर सकते हैं जिसके माध्यम से आप ऑटोलॉड को कॉन्फ़िगर करते हैं, और PHPStan विश्लेषण को सरल बनाने के लिए कुछ अतिरिक्त फाइलें संलग्न करते हैं।

मुख्य विशेषताएं:

संपूर्ण कोड आधार का विश्लेषण करना संभव है, लेकिन केवल एक हिस्सा - अज्ञात कक्षाएं PHPStan ऑटोलॉड को लोड करने का प्रयास करेगी।
यदि किसी कारण से आपकी कुछ कक्षाएं ऑटोलॉड में नहीं हैं, तो PHPStan उन्हें ढूंढ नहीं पाएगा और एक त्रुटि देगा।
यदि आप __call / __get / __set माध्यम से सक्रिय रूप से जादू के तरीकों का उपयोग कर रहे हैं, तो आप PHPStan के लिए एक प्लगइन लिख सकते हैं। सिम्फनी, सिद्धांत, लारवेल, मॉकरी, आदि के लिए प्लगइन्स पहले से मौजूद हैं।
वास्तव में, PHPStan न केवल अज्ञात वर्गों के लिए, बल्कि सभी के लिए सामान्य रूप से ऑटोलॉड का प्रदर्शन करता है। हमारे पास अनाम कक्षाओं की उपस्थिति से पहले लिखे गए बहुत सारे पुराने कोड हैं, जब हम एक फ़ाइल में एक क्लास बनाते हैं, और फिर इसे तुरंत इंस्टेंट कर देते हैं और संभवतः, कुछ तरीकों को भी कॉल करते हैं। ऐसी फ़ाइलों का ऑटोलॉड ( include ) त्रुटियों की ओर जाता है, क्योंकि कोड को सामान्य वातावरण में निष्पादित नहीं किया जाता है।
नियोन प्रारूप में कन्फिग्स (मैंने कभी नहीं सुना कि इस तरह के प्रारूप का उपयोग कहीं और किया गया था)।
उनके @phpstan-var, @phpstan-return टैग जैसे @phpstan-var, @phpstan-return , आदि के लिए कोई समर्थन नहीं है।

एक और विशेषता यह है कि त्रुटियों में पाठ है, लेकिन कोई प्रकार नहीं है। उदाहरण के लिए, त्रुटि पाठ आपको वापस कर दिया गया है:

Method \SomeClass::getAge() should return int but returns int|null
Method \SomeOtherClass::getName() should return string but returns string|null

इस उदाहरण में, दोनों त्रुटियां मूल रूप से एक ही चीज के बारे में हैं: विधि को एक प्रकार वापस करना होगा, लेकिन वास्तव में यह दूसरे को लौटाता है। लेकिन त्रुटियों के ग्रंथ अलग हैं, हालांकि समान हैं। इसलिए, यदि आप PHPStan में किसी भी त्रुटि को फ़िल्टर करना चाहते हैं, तो इसे केवल नियमित अभिव्यक्तियों के माध्यम से करें।

तुलना के लिए, अन्य विश्लेषणकर्ताओं में, त्रुटियों का एक प्रकार है। उदाहरण के लिए, फ़ान में, ऐसी त्रुटि PhanPossiblyNullTypeReturn प्रकार की है, और आप उस कॉन्फ़िगरेशन में निर्दिष्ट कर सकते हैं जिसे आपको ऐसी त्रुटियों के लिए जांचने की आवश्यकता नहीं है। इसके अलावा, त्रुटि के प्रकार, उदाहरण के लिए, त्रुटियों पर आंकड़े एकत्र करना आसान है।

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

हालाँकि, PHPStan हमारे लिए उपयोगी है:

यदि आपको कई फ़ाइलों की जांच करने की आवश्यकता है, तो PHPStan, Phan की तुलना में कहीं अधिक तेज और Psalm की तुलना में थोड़ा (20-50%) तेज है।
PHPStan रिपोर्ट अन्य एनालाइज़र में false-positive खोज करना आसान बनाती है। आमतौर पर, यदि कोड में कुछ स्पष्ट fatal है, तो यह सभी विश्लेषणकर्ताओं (या तीन में से कम से कम दो) द्वारा दिखाया गया है।

अपडेट:
PHPStan Ondřej Mirtes के लेखक ने भी हमारे लेख को पढ़ा और हमें बताया कि भजन की तरह PhStStan में एक "सैंडबॉक्स": https://phpstan.org/ के साथ एक वेबसाइट है। बग रिपोर्ट के लिए यह बहुत सुविधाजनक है: आप त्रुटि को पुन: उत्पन्न करते हैं और गिटहब में एक लिंक देते हैं।

फ़ान

Etsy द्वारा विकसित। पहली बार रासमस लेरडोर्फ से

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

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

हुड के तहत, फन php-ast एक्सटेंशन का उपयोग करता है। जाहिर है, यह एक कारण है कि पूरे कोड आधार का विश्लेषण अपेक्षाकृत जल्दी है। लेकिन php-ast एएसटी ट्री के आंतरिक प्रतिनिधित्व को दर्शाता है क्योंकि यह PHP में ही दिखाई देता है। और PHP में ही, एएसटी ट्री में उन टिप्पणियों के बारे में जानकारी नहीं होती है जो फ़ंक्शन के अंदर स्थित हैं। अर्थात्, यदि आपने कुछ ऐसा लिखा है:

 /** * @param int $type */ function doSomething($type) {   /** @var \My\Object $obj **/   $obj = MyFactory::createObjectByType($type);   … }

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

दूसरी अप्रिय विशेषता यह है कि फान वस्तुओं के गुणों का अच्छी तरह से विश्लेषण नहीं करता है। यहाँ एक उदाहरण है:

 class A { /** * @var string|null */ private $a; public function __construct(string $a = null) {      $this->a = $a; } public function doSomething() {      if ($this->a && strpos($this->a, 'a') === 0) {          var_dump("test1");      } } }

इस उदाहरण में, फान आपको बताएगा कि स्ट्रैप में आप अशक्त हो सकते हैं। आप इस समस्या के बारे में यहाँ और जान सकते हैं: https://github.com/phan/phan/issues/204

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

प्लग-इन

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

हम दो प्लगइन्स लिखने में कामयाब रहे। पहले एक बार की जाँच के लिए अभिप्रेत था। हम मूल्यांकन करना चाहते थे कि हमारा कोड PHP 7.3 के लिए कितना तैयार है (विशेष रूप से, यह पता लगाने के लिए कि क्या यह case-insensitive स्थिरांक है)। हम लगभग सुनिश्चित थे कि इस तरह की कोई कमी नहीं थी, लेकिन 12 साल में कुछ भी हो सकता है - इसकी जांच होनी चाहिए। और हमने फ़ान के लिए एक प्लगइन लिखा था जो कि शपथ लेगा अगर तीसरे पैरामीटर को define() में उपयोग किया गया था।

प्लगइन बहुत सरल है

 <?php declare(strict_types=1); use Phan\AST\ContextNode; use Phan\CodeBase; use Phan\Language\Context; use Phan\Language\Element\Func; use Phan\PluginV2; use Phan\PluginV2\AnalyzeFunctionCallCapability; use ast\Node; class DefineThirdParamTrue extends PluginV2 implements AnalyzeFunctionCallCapability { public function getAnalyzeFunctionCallClosures(CodeBase $code_base) : array {   $define_callback = function (       CodeBase $code_base,                  Context $context,                  Func $function,                  array $args    ) {      if (\count($args) < 3) {         return;      }       $this->emitIssue(       $code_base,      $context,      'PhanDefineCaseInsensitiv',      'Define with 3 arguments',      []      );    };    return [          'define' => $define_callback,    ]; } } return new DefineThirdParamTrue();

फ़ान में, अलग-अलग प्लगइन्स को अलग-अलग घटनाओं पर लटका दिया जा सकता है। विशेष रूप से, एक फ़ंक्शन कॉल पार्स होने पर AnalyzeFunctionCallCapability इंटरफ़ेस के साथ प्लगइन्स चालू हो AnalyzeFunctionCallCapability । इस प्लगइन में, हमने इसे इसलिए बनाया है कि जब हम define() फ़ंक्शन define() कॉल करते define() , तो हमारा अनाम फ़ंक्शन कहलाता है, जो define() करता है कि चेक define() दो से अधिक तर्क नहीं हैं। फिर हमने बस फ़ैन शुरू किया, सभी स्थानों define() जहां define() तीन तर्कों के साथ बुलाया गया था, और यह सुनिश्चित किया कि हमारे पास case-insensitive- ।

प्लगइन का उपयोग करते हुए, हमने Phan को कोड के अंदर PHPDoc संकेत नहीं देखने पर आंशिक रूप से false-positive समस्या हल कर दी।

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

 /** @var \Objects\Controllers\My $Object */ $Object = \Objects\Factory::create(\Objects\Config::MY_CONTROLLER);

फ़ान को ऐसे PHPDoc संकेत समझ में नहीं आते हैं, लेकिन इस कोड में ऑब्जेक्ट क्लास को निरंतर पास के नाम से बनाया जा सकता है create() विधि। फ़ान आपको एक प्लगइन लिखने की अनुमति देता है जो किसी फ़ंक्शन के रिटर्न मान का विश्लेषण करते समय आग लग जाती है। और इस प्लगइन के साथ, आप विश्लेषक को बता सकते हैं कि इस कॉल में फ़ंक्शन रिटर्न किस प्रकार का है।

इस प्लगइन का एक उदाहरण अधिक जटिल है। लेकिन vendor/phan/phan/src/Phan/Plugin/Internal/DependentReturnTypeOverridePlugin.php. में Phan कोड में एक अच्छा उदाहरण है vendor/phan/phan/src/Phan/Plugin/Internal/DependentReturnTypeOverridePlugin.php.

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

भजन

स्तोत्र Vimeo द्वारा एक विकास है। ईमानदारी से, मुझे यह भी पता नहीं था कि जब तक मैंने स्तोत्र को नहीं देखा, तब तक वीमो PHP का उपयोग करता है

यह विश्लेषक हमारे तीनों में सबसे छोटा है। जब मैंने खबर पढ़ी कि वीमो ने भजन को जारी किया, तो मैं एक नुकसान में था: "यदि आपके पास पहले से ही फ़ान और PHPStan है तो भजन में निवेश क्यों करें?" लेकिन यह पता चला कि भजन की अपनी उपयोगी विशेषताएं हैं।

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

Psalm में सैंडबॉक्स वाली साइट है जहाँ आप PHP कोड लिख सकते हैं और उसका विश्लेषण कर सकते हैं। बग रिपोर्ट के लिए यह बहुत सुविधाजनक है: आप साइट पर त्रुटि को पुन: उत्पन्न करते हैं और गिटहब में लिंक देते हैं। और वैसे, साइट सभी संभावित प्रकार की त्रुटियों का वर्णन करती है। तुलना के लिए: PHPStan त्रुटियों में कोई प्रकार नहीं है, और Phan में वे हैं, लेकिन कोई एकल सूची नहीं है जो मिल सकती है।

हमें यह भी पसंद आया कि त्रुटियों को आउटपुट करते समय, भजन तुरंत कोड की पंक्तियों को दिखाता है जहां वे पाए गए थे। यह पढ़ने की रिपोर्ट को बहुत सरल करता है।

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

@ स्तोत्र-उपेक्षा-अशक्त-वापसी

ऐसा होता है कि औपचारिक रूप से एक विधि null , लेकिन कोड पहले से ही इस तरह से व्यवस्थित है कि ऐसा कभी नहीं होता है। इस मामले में यह बहुत सुविधाजनक है कि आप विधि / कार्य के लिए बस इस तरह के एक PHPDoc संकेत जोड़ सकते हैं - और भजन यह विचार करेगा कि null वापस नहीं आया है।

एक समान संकेत झूठ के लिए मौजूद है: @psalm-ignore-falsable-return ।

बंद करने के प्रकार

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

 function my_filter(array $ar, \Closure $func) { … }

एक प्रोग्रामर यह कैसे समझ सकता है कि दूसरे पैरामीटर में फ़ंक्शन का कौन सा इंटरफ़ेस है? इसे क्या पैरामीटर लेना चाहिए? उसे क्या लौटना चाहिए?

भजन PHPDoc में कार्यों का वर्णन करने के लिए वाक्यविन्यास का समर्थन करता है:

 /** * @param array $ar * @psalm-param Closure(int):bool $func */ function my_filter(array $ar, \Closure $func) { … }

इस विवरण के साथ, यह पहले से ही स्पष्ट है कि आपको my_filter को एक अनाम फ़ंक्शन पास करना होगा, जो एक इंट और रिटर्न बूल स्वीकार करेगा। और, ज़ाहिर है, भजन यह सत्यापित करेगा कि आपके पास अपने कोड में ऐसा कोई फ़ंक्शन है।

enums

मान लें कि आपके पास एक फ़ंक्शन है जो एक स्ट्रिंग पैरामीटर लेता है, और आप केवल वहां कुछ स्ट्रिंग पास कर सकते हैं:

 function isYes(string $yes_or_no) : bool {     $yes_or_no = strtolower($yes_or_no)     switch($yes_or_no)  {           case 'yes':                 return true;          case 'no':                 return false;           default:                throw new \InvalidArgumentException(…);     } }

भजन आपको इस फ़ंक्शन के पैरामीटर का वर्णन करने की अनुमति देता है:

 /** @psalm-param 'Yes'|'No' $yes_or_no **/ function isYes(string $yes_or_no) : bool { … }

इस मामले में, भजन यह समझने की कोशिश करेगा कि इस फ़ंक्शन के लिए क्या विशिष्ट मान पारित किए गए हैं, और यदि Yes और No अलावा अन्य मान हैं, तो त्रुटियों को फेंक दें No

एनम के बारे में और अधिक पढ़ें।

उपनाम लिखें

इससे पहले array shapes के वर्णन में array shapes मैंने उल्लेख किया कि यद्यपि विश्लेषक आपको सरणियों की संरचना का वर्णन करने की अनुमति देते हैं, लेकिन इसका उपयोग करना बहुत सुविधाजनक नहीं है, क्योंकि सरणी के विवरण को विभिन्न स्थानों में कॉपी करना होगा। बेशक, सही समाधान, सरणियों के बजाय कक्षाओं का उपयोग करना है। लेकिन विरासत के कई वर्षों के मामले में, यह हमेशा संभव नहीं होता है।

, , , :

;
closure;
union- (, );
enum.

, , PHPDoc , , . Psalm . alias PHPDoc alias . , : PHP-. . , Psalm.

Generics aka templates

. , :

 function identity($x) { return $x; }

? ? ?

, , , — mixed , .

mixed — . , . , identity() / , : , . -. , :

 $i = 5; // int $y = identity($i);

(int) , , $y ( int ).

? Psalm PHPDoc-:

 /** * @template T * @psalm-param T $x * @psalm-return T */ function identity($x) { $return $x; }

templates Psalm , / .

Psalm templates:

— vendor/vimeo/psalm/src/Psalm/Stubs/CoreGenericFunctions.php ;
— vendor/vimeo/psalm/src/Psalm/Stubs/CoreGenericClasses.php .

Phan, : https://github.com/phan/phan/wiki/Generic-Types .

, Psalm . , «» . , Psalm , , Phan PHPStan. .

PHPStorm

: , . , , .

. Phan, language server. PHPStorm, , .

, , PHPStorm ( ), . — Php Inspections (EA Extended). — , , . , . , scopes - scopes.

, deep-assoc-completion . .

Badoo

?

, .

, . , , git diff / , , () . , .

, : - git diff . . , . . , , , , .

, , :

false-positive . , , Phan , , . , - Phan , , .

QA

— , , , . :

100% ( , );
, code review;
, .

strict types . , strict types , :

, strict types , ;
, (, , );
, PHP (, union types , PHP);
strict types , .

:

, . .

-, , , - , .

-, , — , , PHPDoc. — .

-, . , - , PHPDoc. :)

, , . , .

एक उदाहरण के रूप में PHPStan, Phan और Psalm का उपयोग करके PHP कोड का स्थैतिक विश्लेषण