स्टेटिक कोड विश्लेषण के बारे में मिथकों को तोड़ना

मंचों पर लोगों के साथ संवाद करते हुए, मैंने स्थैतिक विश्लेषण पद्धति के बारे में कई लगातार गलत धारणाएं देखीं। मैं निम्नलिखित मिथकों को दूर करना चाहता हूं:

1. स्टेटिक विश्लेषक एक बार का उत्पाद है।
2. पेशेवर डेवलपर्स मूर्खतापूर्ण गलती नहीं करते हैं।
3. गतिशील विश्लेषण स्थैतिक विश्लेषण से बेहतर है।
4. प्रोग्रामर अपने नियमों को स्टैटिक एनालाइजर से जोड़ना चाहते हैं।

मिथक वन - एक स्टैटिक एनालाइजर वन टाइम प्रोडक्ट है

यहाँ एक मंच पर चर्चा करते समय यह कथन कैसा दिखता है (सामूहिक छवि):

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

हर कोई खुश है। लोगों ने जाँच की। विश्लेषक के डेवलपर्स को यह पता नहीं चला कि उन्हें धोखा दिया गया था और लूट लिया गया था।

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

सादृश्य:

हम संकलक चेतावनी स्तर / W0 सेट करते हैं। और हम एक परियोजना विकसित कर रहे हैं। हम कसम खाते हैं, हम बेवकूफ गलतियों और टाइपो को सही करते हैं, हम अधिक और लंबे समय तक परीक्षण करते हैं। फिर कभी-कभी / W3 चालू करें और चेतावनी के साथ लड़ें, और फिर / W0 पर वापस लौटें। उसी समय, कंपाइलर / डब्ल्यू 3 स्तर पर हम क्या निडरता से सुझाव दे सकते थे और लंबे समय तक डिबगर में खोजा और इस पर 10-100 गुना अधिक समय बिताया। इसके अलावा, ध्यान दें कि प्रोग्रामर / W3 परिणाम पसंद नहीं करेगा। आखिरकार, उन्होंने परीक्षण और डीबगिंग द्वारा लगभग सभी त्रुटियों को ठीक किया। स्तर / W3 पर कंपाइलर अब ज्यादातर गलत पॉजिटिव पैदा करता है।

अब वापस स्थैतिक विश्लेषण के लिए। तस्वीर पूरी तरह से समान है। विश्लेषक का एक दुर्लभ लॉन्च बहुत सारी झूठी सकारात्मकता देता है। ये त्रुटियां कुछ कम हैं, क्योंकि वे अन्य तरीकों से पाए जाते हैं।

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

चर्चा की गर्मी में कुछ इस तरह से जवाब देते हैं:

नौसिखिया छात्रों के लिए यह विचार सही है। विशेषज्ञों के लिए, यह इतना महत्वपूर्ण नहीं है। अगर मैं / W0 लगाऊंगा तो मैं बुरा नहीं लिखूंगा। प्रोग्रामिंग शैली में सुधार करना आवश्यक है, और बैसाखी साधनों की संख्या में वृद्धि नहीं करना।

मैं ऊपर लिखी हर बात से पूरी तरह सहमत हूं। लेकिन चलो खेलते हैं और इस तरह से पाठ को फिर से करें:

नौसिखिए ड्राइवरों के लिए विचार सही है। पेशेवरों के लिए, यह इतना महत्वपूर्ण नहीं है। अगर मैं अपना सीटबेल्ट नहीं हटाता हूं, तो मुझे इससे बुरा नहीं लगता। ड्राइविंग शैली में सुधार करना आवश्यक है, और सुरक्षा घटकों की संख्या में वृद्धि नहीं करना।

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

दूसरा मिथक - पेशेवर डेवलपर्स बेवकूफ गलतियाँ नहीं करते हैं

दूसरा मिथक: "पेशेवर डेवलपर्स बेवकूफ गलतियाँ नहीं करते हैं, जो मुख्य रूप से स्थैतिक कोड विश्लेषक द्वारा पकड़े जाते हैं।"

यहाँ एक मंच पर चर्चा करते समय यह कथन कैसा दिखता है (सामूहिक छवि):

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

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

ऐसा नहीं है। कोई भी प्रोग्रामर बेवकूफ गलतियाँ करता है। मुझे पता है कि आपने मुझे नहीं सुना। मैं विधर्मी विचारों को दोहराता हूं। सभी प्रोग्रामर बेवकूफ बनाते हैं। इससे कोई फर्क नहीं पड़ता कि वे किस तरह के पेशेवर हैं। लोग गलतियाँ करते हैं। और अक्सर ये त्रुटियां सरल होती हैं।

त्रुटियों के बारे में मेरे बयान के बारे में प्रोग्रामर बहुत ही बेफ़िक्र हैं। उनकी राय में, यह वे थे जिन्होंने बहुत लंबे समय तक ऐसी गलतियाँ नहीं की थीं। मुझे लगता है कि मानस का एक दिलचस्प पहलू यहां काम करता है, बिना किसी प्रोग्रामिंग के क्षणों की स्मृति को छानना।

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

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

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

निष्कर्ष। प्रोग्रामर ज्यादा से ज्यादा समय टाइपिंग फिक्सिंग में बिताते हैं जितना वे सोचते हैं। स्थैतिक विश्लेषण उपकरण परीक्षण चरण से पहले ही इन त्रुटियों में से कुछ की पहचान करके डेवलपर्स के प्रयासों को महत्वपूर्ण रूप से बचा सकते हैं।

मिथक तीन - गतिशील विश्लेषण स्थिर से बेहतर है

मिथक तीन: "सी / सी ++ के लिए वेलग्रिंड जैसे उपकरणों के साथ गतिशील सत्यापन स्थैतिक कोड विश्लेषण की तुलना में बहुत अधिक उत्पादक है।"

बल्कि बयान अजीब है। गतिशील और स्थिर विश्लेषण केवल दो अलग-अलग तरीके हैं जो एक दूसरे के पूरक हैं। प्रोग्रामर इसे समझने लगते हैं। लेकिन मैं बार-बार सुनता हूं कि गतिशील विश्लेषण स्थिर से बेहतर है।

मैं स्थिर कोड विश्लेषण की ताकत की सूची दूंगा।

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

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

  fp = fopen (नाम, "wb");
 int x = 0;
 अगर (fp)
   int x = 1; 

यदि फ़ाइल नहीं खोली गई तो 'x' ध्वज एक के बराबर नहीं होगा। इस तरह की त्रुटियों के कारण यह ठीक है कि जब कार्यक्रमों में कुछ गलत होता है, तो वे पर्याप्त त्रुटि संदेशों के बजाय गिर जाते हैं या अर्थहीन संदेश देते हैं।

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

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

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

  शून्य मैपडेस्क :: पहचान (वास्तविक भाग्य [MAXCOORDS] [MAXCOORDS])
 {
   memset (भाग्य, 0, आकार (भाग्य));
   (int i = 0; i; = hcoords; i ++) के लिए
     भाग्य [i] [i] = 1.0;
 } 

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

या यहाँ क्लैंग परियोजना से एक और उदाहरण है:

  MapTy PerPtrTopDown;
 MapTy PerPtrBottomUp;
 शून्य साफ़ करें
   PerPtrTopDown.clear ();
 }
 शून्य क्लियरटाइपडाउनपॉइंटर्स () {
   PerPtrTopDown.clear ();
 } 

डायनेमिक एनालाइजर यहां क्या संदेह कर सकता है? कोई बात नहीं। एक स्थिर विश्लेषक को कुछ गलत होने का संदेह हो सकता है। यहाँ त्रुटि यह है कि ClearBottomUpPointers () के अंदर होना चाहिए: "PerPtrBottomUp.clear ();"।

मिथक चार - प्रोग्रामर एक स्थिर विश्लेषक के लिए अपने नियमों को जोड़ना चाहते हैं

मिथक फोर: “एक स्थिर विश्लेषक कस्टम नियमों को जोड़ने में सक्षम होना चाहिए। प्रोग्रामर अपने नियम जोड़ना चाहते हैं। "

नहीं, वे नहीं करना चाहते हैं। वास्तव में, वे कुछ भाषा निर्माणों की खोज की कुछ समस्याओं को हल करना चाहते हैं। और यह नैदानिक ​​नियम बनाने के समान नहीं है।

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

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

इससे मुद्दे की मेरी समझ खत्म हो गई। दिमित्री ने व्यापक अनुभव रखते हुए इसका विस्तार किया। संक्षेप में, स्थिति इस तरह दिखती है।

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

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

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

पाठक ध्यान देगा: "फिर एपीआई में केवल 1% कार्यक्षमता खोलें और हर कोई खुश होगा।" हां, यह सही है। लेकिन देखो कैसे जोर दिया गया है। अपने नियमों को विकसित करने से, हम इस निष्कर्ष पर पहुंचे कि वास्तव में grep जैसा ही एक उपकरण है, लेकिन प्रोग्राम कोड के बारे में कुछ अतिरिक्त जानकारी रखने के लिए पर्याप्त है।

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

वैसे, शायद ऐसा उपकरण अंततः इंटेल सी ++ के ढांचे में दिखाई देगा। दिमित्री पेटुनिन ने कहा कि वे कोड संरचना और चर के प्रकार के ज्ञान के साथ एक ग्रीप जैसे उपकरण बनाने की संभावना पर चर्चा कर रहे थे। लेकिन इस पर एक अमूर्त तरीके से चर्चा हुई। मुझे नहीं पता कि क्या वास्तव में इसे बनाने की योजना है या नहीं।