कोड एनालाइज़र की तुलना में कठिनाइयाँ या प्रयोज्य को मत भूलना

उपयोगकर्ताओं की आपस में विभिन्न कोड एनालाइजर की तुलना करने की इच्छा समझने योग्य और स्वाभाविक है। हालांकि, इस इच्छा को महसूस करना उतना सरल नहीं है जितना कि यह पहली नज़र में लग सकता है। तथ्य यह है कि यह स्पष्ट नहीं है कि एक दूसरे के साथ तुलना करने के लिए कौन से विशिष्ट कारक हैं।

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

क्या आपको संदेह है कि इन मापदंडों की तुलना करने का कोई मतलब नहीं है? यहाँ कुछ उदाहरण हैं।

तुलना करने के लिए कौन से पैरामीटर सरल हैं

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

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

उदाहरण के लिए, क्लोकवर्क टूल, जो विदेशी सहित विभिन्न प्रणालियों की एक विस्तृत विविधता का समर्थन करता है। इनमें से एक प्रणाली में एक संकलक होता है जो निम्नलिखित कोड को "निगल" करता है:

  इनलाइन इंट एक्स; 

Klocwork विश्लेषक के पास एक नैदानिक ​​संदेश है जो आपको कोड में इस विसंगति का पता लगाने की अनुमति देता है: "इनलाइन 'कीवर्ड फ़ंक्शन या विधि के अलावा किसी अन्य चीज़ पर लागू होता है"। यह पता चला है कि यह अच्छा लगता है कि इस तरह का निदान है। लेकिन, कहते हैं, Microsoft Visual C ++ कंपाइलर या किसी अन्य पर्याप्त संकलक का उपयोग करने वाले डेवलपर को इस डायग्नोस्टिक से कोई लाभ नहीं है। विजुअल C ++ केवल ऐसे कोड को संकलित नहीं करता है: "त्रुटि C2433: 'x': 'इनलाइन' डेटा घोषणाओं की अनुमति नहीं है"।

एक और उदाहरण। कुछ संकलक बूल प्रकार का अच्छी तरह से समर्थन नहीं करते हैं। इसलिए, क्लोकवर्क एक स्थिति के बारे में चेतावनी दे सकता है जब एक वर्ग सदस्य प्रकार का होता है: "PORTING.STRUCT.BOOL: यह चेकर उन स्थितियों का पता लगाता है जिसमें एक संरचना / वर्ग में एक बूल सदस्य होता है"।

उन्होंने कक्षा में एक बूल लिखा, वह डरावनी है ... यह स्पष्ट है कि डेवलपर्स का एक बहुत छोटा प्रतिशत इस तरह के निदान संदेश से लाभ उठा सकता है।

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

इसलिए, हमें पता चला कि नैदानिक ​​जांच की संख्या के रूप में इस तरह के एक पैरामीटर द्वारा विश्लेषक उपयोगिता की तुलना करना असंभव है।

हम कह सकते हैं: “तो फिर आइए एक विशेष प्रणाली के लिए प्रासंगिक चेक की संख्या की तुलना करें। उदाहरण के लिए, हम उन सभी नियमों का चयन करेंगे जो हमें विंडोज कार्यक्रमों में त्रुटियों की तलाश करने की अनुमति देते हैं। ” लेकिन यह दृष्टिकोण दो कारणों से काम नहीं करता है:

सबसे पहले, यह अक्सर होता है कि कुछ विश्लेषक में चेक को एक नैदानिक ​​नियम द्वारा लागू किया जाता है, और दूसरे में कई नियमों द्वारा। और यदि हम नैदानिक ​​नियमों की संख्या से तुलना करते हैं, तो ऐसा लगता है कि विश्लेषणकर्ताओं में से एक बेहतर है, हालांकि वे ज्ञात त्रुटियों के मामले में समान हैं।

दूसरे, कुछ निदानों का कार्यान्वयन अलग-अलग गुणवत्ता का हो सकता है। उदाहरण के लिए, लगभग सभी विश्लेषकों के पास "जादुई संख्या" की खोज है। लेकिन, उदाहरण के लिए, एक विश्लेषक में केवल जादू की संख्या का पता लगाया जा सकता है, 64-बिट सिस्टम (4, 8, 32, आदि) के लिए कोड ट्रांसफर के दृष्टिकोण से खतरनाक है, फिर दूसरे में - बस सभी जादू नंबर (1, 2) , 3, आदि)। और बस वहाँ और वहाँ डाल करने के लिए "जादू संख्या के लिए खोज" कॉलम में तुलना तालिका में, "प्लस" पर्याप्त नहीं होगा।

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

उचित तुलना के लिए उपकरण की उपयोगिता बहुत महत्वपूर्ण है।

तथ्य यह है कि कोड एनालाइजर के वास्तविक उपयोग में एक बहुत ही महत्वपूर्ण भूमिका निभाई जाती है कि उपकरण कितना सुविधाजनक है ...

हमने हाल ही में इस कोड की सुविधा का मूल्यांकन करते हुए, दो कोड एनालाइज़र के साथ eMule प्रोजेक्ट का परीक्षण किया। उनमें से एक दृश्य स्टूडियो के कुछ संस्करणों में बनाया गया एक स्थिर विश्लेषक था। दूसरा हमारा PVS-Studio है । और हमने तुरंत Visual Studio में निर्मित कोड विश्लेषक के साथ काम करने में कई समस्याएं देखीं। इसके अलावा, ये समस्याएं विश्लेषण और गति की बहुत गुणवत्ता से संबंधित नहीं हैं।

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

दूसरी समस्या यह है कि डुप्लिकेट विश्लेषक संदेशों के प्रसंस्करण को कैसे लागू किया जाता है। यह हेडर फ़ाइलों (.h फ़ाइलों) में समस्याओं के निदान के बारे में है। विश्लेषक को .h फ़ाइल में एक समस्या का पता लगाने दें जो दस .cpp फ़ाइलों में शामिल है। इन दस .cpp फ़ाइलों में से प्रत्येक का विश्लेषण करके, Visual Studio में निर्मित विश्लेषक समस्या के बारे में एक ही संदेश को .h दस बार में प्रदर्शित करता है! एक ठोस उदाहरण। ई-मेल संदेश की जाँच करते समय

  c: \ Users \ evg \ दस्तावेज \ emuleplus \ Dialmintraybtn.hpp (450): 
 चेतावनी C6054: स्ट्रिंग 'szwThemeColor' शून्य-समाप्त नहीं हो सकती है:
 तर्ज: 434, 437, 438, 443, 445, 448, 450 

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

तीसरी समस्या सिस्टम फ़ाइलों में समस्याओं के लिए संदेश जारी करने की है (फॉर्म C: \ Program Files (x86) \ Microsoft Visual Studio 10.0 \ VC \ _ के फ़ोल्डर से) शामिल हैं। विज़ुअल स्टूडियो में निर्मित विश्लेषक ब्रांडिंग सिस्टम हेडर फ़ाइलों के बारे में शर्मीला नहीं है, हालांकि इसमें बहुत व्यावहारिक अर्थ नहीं है। फिर से, एक उदाहरण। ई-मेल की जाँच करते समय, सिस्टम फ़ाइलों के बारे में एक ही संदेश कई बार मिला:

  1> c: \ program files (x86) \ microsoft
 sdks \ windows \ v7.0a \ शामिल \ ws2tcpip.h (729): 
 चेतावनी C6386: बफर उग आया: 'तर्क 1' तक पहुँचना, 
 लिखने योग्य आकार '1 * 4' बाइट्स है, 
 लेकिन '4294967272' बाइट लिखा जा सकता है: 
 लाइन्स: 703, 704, 705, 707, 713, 714, 715, 720, 
 721, 722, 724, 727, 728, 729 

वैसे भी, कोई भी सिस्टम फ़ाइलों को संपादित नहीं करेगा। तो ऐसी फाइलों पर "कसम" क्यों? पीवीएस-स्टूडियो ने सिस्टम फाइलों पर कभी शपथ नहीं ली।

इसमें उपकरण को इंगित करने में असमर्थता भी शामिल है कि यह मास्क द्वारा कुछ फ़ाइलों को स्कैन नहीं करता है। उदाहरण के लिए, सभी फाइलें "* _generated.cpp" या "c: \ libs \" हैं। पीवीएस-स्टूडियो में, आप बाहर की गई फ़ाइलों को निर्दिष्ट कर सकते हैं।

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

पांचवीं समस्या संदेशों को न केवल कोड द्वारा, बल्कि पाठ द्वारा भी फ़िल्टर करना है। उदाहरण के लिए, "प्रिंटफ" वाले सभी संदेशों को छिपाना उपयोगी है। दृश्य स्टूडियो में निर्मित विश्लेषक में ऐसी कोई संभावना नहीं है, यह पीवीएस-स्टूडियो में है।

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

इन सभी समस्याओं के छह, हालांकि वे कोड विश्लेषण की गुणवत्ता को प्रभावित नहीं करते हैं, बहुत महत्व के हैं। आखिरकार, उपकरण की प्रयोज्यता वह अभिन्न संकेतक है जिस पर यह निर्भर करता है: विश्लेषण की गुणवत्ता का आकलन करने की बात आती है या नहीं।

कुल मिलाकर, हमें निम्न चित्र मिलते हैं। EMule प्रोजेक्ट की जाँच विज़ुअल स्टूडियो में निर्मित स्टैटिक एनालाइज़र द्वारा की जाती है, जो PVS-Studio की तुलना में कई गुना तेज होता है। लेकिन विज़ुअल स्टूडियो विश्लेषक (वास्तव में कम, लेकिन मुझे आराम करने के लिए अन्य कार्यों में स्विच करना पड़ा) के साथ काम करने में 3 दिन लगे। और पीवीएस-स्टूडियो के साथ काम करने में केवल 4 घंटे लगे।

नोट। मिली त्रुटियों की संख्या के बारे में, दोनों विश्लेषणकर्ताओं ने लगभग समान परिणाम दिखाए, और इस परियोजना में समान त्रुटियां पाईं।

निष्कर्ष

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