स्थैतिक विश्लेषण और खोज इंजन क्या आम हैं? अच्छा "शीर्ष"!

Google / Yandex जैसे खोज इंजन डेवलपर्स और स्थिर कोड विश्लेषण टूल के डेवलपर्स एक बहुत ही समान समस्या को हल करते हैं। उन दोनों को और दूसरों को उपयोगकर्ता को उन संसाधनों के साथ कुछ चयन प्रदान करना चाहिए जो उपयोगकर्ता की इच्छाओं को "पूरा" करते हैं। नहीं, निश्चित रूप से, आदर्श रूप से, खोज इंजन डेवलपर्स खुद को "आई एम फीलिंग लकी" बटन (आई एम फीलिंग लकी) तक सीमित करना चाहते हैं। और कोड विश्लेषण टूल के डेवलपर्स कोड में केवल वास्तविक त्रुटियों की एक सूची देना चाहते हैं। लेकिन वास्तविकता, हमेशा की तरह, सीमाएं लगाती है। यह जानना चाहते हैं कि पीवीएस-स्टूडियो विकसित करते समय हम कैसे क्रूर वास्तविकता से निपटते हैं?

परिचय

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

कोड एनालाइज़र के दृष्टिकोण से, कार्य लगभग समान दिखता है। उपयोगकर्ता के पहले से ही निहित प्रश्न ("स्मार्ट प्रोग्राम, मुझे दिखाओ कि मुझे कोड में कहां त्रुटियां हैं?"), टूल को प्रोग्राम में कोड के टुकड़े को इंगित करना चाहिए जो उपयोगकर्ता को सबसे अधिक पसंद करते हैं।

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

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

स्थैतिक विश्लेषण के लिए "सही आउटपुट" कैसे प्रदान करें?

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

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

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

तीसरा, हम लगातार झूठी सकारात्मकता के साथ संघर्ष करते हैं।

खैर, आप यह सब कैसे करते हैं?

हमारे पास एक आंतरिक उपकरण है जो हमें सांख्यिकीय ("स्थिर" के साथ भ्रमित नहीं होने की अनुमति देता है!) हमारे कोड विश्लेषक के परिणामों का विश्लेषण। यह आपको तीन मापदंडों का मूल्यांकन करने की अनुमति देता है:

• परियोजना में त्रुटियों का अनुपात परियोजना स्तर (प्रोजेक्ट स्तर साझा) में त्रुटियों (कोड द्वारा) का प्रसार है।
• औसत त्रुटि घनत्व - एक प्रकार की त्रुटियों की संख्या का अनुपात फ़ाइलों की संख्या जिसमें इस प्रकार की त्रुटि होती है (औसत घनत्व (परियोजना स्तर))।
• प्रोजेक्ट फ़ाइलों के बीच एक ही प्रकार की त्रुटियों का वितरण उनके औसत घनत्व (फ़ाइल में त्रुटियां गिना जाता है) की तुलना में।

आइए मिरांडा IM परियोजना पर एक बेहतर नज़र डालें क्योंकि हम इस आंतरिक उपकरण का उपयोग करते हैं।

मैं अभी यह कहना चाहूंगा कि यह पोस्ट मिरांडा IM में मिली त्रुटियों के बारे में नहीं है। यदि आप त्रुटियों को देखना चाहते हैं, तो इस नोट को देखें।

तो, हमारे आंतरिक उपकरण में परीक्षा परिणाम (फ़ाइल को रोकें) खोलें, 3 त्रुटि स्तर को बंद करें और केवल GA-विश्लेषक (सामान्य विश्लेषण) को छोड़ दें। परिणामस्वरूप, त्रुटि वितरण चित्र 1 में होगा।

चित्रा 1 - मिरांडा आईएम परियोजना में त्रुटियों का वितरण।

रंगीन क्षेत्रों - यह पता चला समस्याओं की कुल संख्या के एक विशेष निदान के "ट्रिगर" से 2.5% से अधिक है। काला - 2.5% से कम। यह देखा जा सकता है कि सबसे आम त्रुटियां कोड V547, V595 और V560 के साथ थीं। इन कोड्स को याद रखें।

चित्र 2 प्रत्येक प्रकार की त्रुटियों की प्रति परियोजना फ़ाइल (यानी, उनकी औसत घनत्व प्रति परियोजना) दिखाता है।

चित्रा 2 - मिरांडा आईएम परियोजना में औसत त्रुटि घनत्व।

यह ग्राफ़ दिखाता है कि कोड V547, V595 और V560 की त्रुटियां लगभग 1.5 से 2.5 गुना प्रति फ़ाइल होती हैं। यह, वास्तव में, एक सामान्य संकेतक है और झूठी त्रुटियों के दृष्टिकोण से इन त्रुटियों को "लड़ाई" करने का कोई कारण नहीं है। लेकिन अंत में यह इन त्रुटियों के लिए तीसरे ग्राफ की पुष्टि कर सकता है, जो आंकड़े 3,4,5 में दिखाए गए हैं।

चित्रा 3 - मिरांडा आईएम परियोजना में V547 त्रुटियों का वितरण उनके औसत घनत्व के साथ तुलना में।

चित्रा 4 - मिरांडा आईएम परियोजना में V595 त्रुटियों का वितरण उनके औसत घनत्व के साथ तुलना में।

चित्रा 5 - मिरांडा आईएम परियोजना में V560 त्रुटियों का वितरण उनके औसत घनत्व की तुलना में।

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

तो इन ग्राफ के साथ क्या करना है?

फिर हम इन "लाल" फाइलों को देखते हैं और निर्णय लेते हैं - अगर कोई झूठी सकारात्मक है, और यह अक्सर अन्य परियोजनाओं में होता है, तो हम इसके साथ लड़ते हैं। यदि वास्तव में कोई गलती है, और इसके अलावा, कॉपी-पेस्ट तकनीक का उपयोग तेजी से गुणा किया जाता है, तो यहां "सुधार" करने के लिए कुछ भी नहीं है।

इस लेख में, मैं जानबूझकर कोड उदाहरण प्रदान नहीं करता हूं जो विश्लेषक ने कसम खाई थी ताकि पाठ को अव्यवस्थित न करें।

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

और तस्वीरों में ओपी बटन क्या है?

तीन मानक विश्लेषक बटन (जीए, 64, एमपी), एक और ओपी बटन - "अनुकूलन" के लिए कम के अलावा, एक चौकस पाठक ने आंकड़ों में देखा। पीवीएस-स्टूडियो 4.60 में, हमने सूक्ष्म-अनुकूलन से संबंधित नैदानिक ​​नियमों का एक नया समूह पेश किया। संभव सूक्ष्म अनुकूलन का निदान करना हमारे विश्लेषक की एक अस्पष्ट विशेषता है। कोई ऐसी जगह पाकर बहुत खुश होता है, जहाँ एक बड़ी वस्तु को संदर्भ से नहीं, बल्कि कॉपी करके ( V801 ) फंक्शन में पास किया जाता है। कोई व्यक्ति वस्तुओं के बड़े सरणियों ( V802 ) के लिए संरचनाओं के आकार को कम करके स्मृति को बचाता है। और किसी को लगता है कि यह सब बेवकूफी और समयपूर्व अनुकूलन है। यह सब परियोजना के प्रकार पर निर्भर करता है।

किसी भी मामले में, हमारे उपकरण के जारी करने का विश्लेषण करते हुए, हम आवश्यकता पर आए:

• एक अलग समूह में अलग अनुकूलन डायग्नोस्टिक्स ताकि उन्हें आसानी से छिपाया / दिखाया जा सके;
• उन्हें डिफ़ॉल्ट रूप से अक्षम करें, क्योंकि वे उन निदानों के साथ त्रुटि सूची को "रोक" सकते हैं जो हर किसी को पसंद नहीं हैं।

तो पीवीएस-स्टूडियो आउटपुट विंडो (चित्र 6) में नया ओपी बटन दिखाई दिया:

चित्रा 6 - ओपी (अनुकूलन) बटन पीवीएस-स्टूडियो 4.60 में दिखाई दिया।

वैसे, एक ही संस्करण में, हमने 64-बिट समस्याओं के विश्लेषण के लिए झूठी सकारात्मक की संख्या को काफी कम कर दिया है।

मेरा सुझाव है कि पीवीएस-स्टूडियो के नए संस्करण को डाउनलोड करना और यह जांचना कि आपके कोड के लिए माइक्रो-ऑप्टिमाइज़ेशन सिफारिशें सफलतापूर्वक कैसे जारी की जाती हैं।

निष्कर्ष

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

दर्शकों का सवाल

मेरे पास उन लोगों के लिए एक छोटा सा प्रश्न है जो पीवीएस-स्टूडियो या किसी अन्य कोड विश्लेषक का उपयोग करते हैं (या कम से कम खेला जाता है)। क्या आपको लगता है कि एंड-यूज़र कोड विश्लेषक को आर्टिकल में एंड-यूज़र टूल के रूप में दिए गए ग्राफिक्स की ज़रूरत है? या, दूसरे तरीके से, यदि आपके कोड विश्लेषक में समान आरेख होते हैं, तो क्या आप उनसे कुछ सीख पाएंगे? या यह विशेष रूप से एक "आंतरिक उपयोग" उपकरण है? कृपया अपनी राय हमें या यहाँ टिप्पणियों में लिखकर साझा करें।