पीसी-लिंट स्टेटिक कोड विश्लेषक

"लॉन्ग बॉक्स" में मामले को अलग न रखने के लिए, मैं स्टेटिक कोड एनालाइज़र का उपयोग करके अपने अनुभव के बारे में कहानी जारी रखूंगा। ( यहां और यहां शुरू करें )।

क्लोकवर्क की कोशिश करने के बाद, मैंने इसमें प्रबंधन को रुचि देने की कोशिश की, लेकिन 30 हजार यूरो की कीमत मुख्य रोक मानदंड के रूप में सेवा की, बाकी सब कुछ अब महत्वपूर्ण नहीं था।

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

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

आउटपुट एक पाठ फ़ाइल में है। विजुअल स्टूडियो से शुरू होने पर - स्टूडियो कंसोल पर, जहां से इसे कथित समस्या के स्थान पर जाने के लिए क्लिक किया जा सकता है (पूरी तरह से आसान!)।

पीसी-लिंट की सबसे बड़ी समस्या संदेशों की संख्या है। अपेक्षाकृत छोटी परियोजना पर, डिफ़ॉल्ट सेटिंग्स के साथ, उन्होंने 23 हजार से अधिक टिप्पणियां जारी कीं! कुछ दिन देखने में और 34 बार "बंद" करने के बाद, समस्याओं के सभी महत्वपूर्ण वर्ग में नहीं, मैंने कुल टिप्पणियों की संख्या को घटाकर साढ़े पाँच हज़ार करने में कामयाबी हासिल की!

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

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

आप एक निश्चित प्रकार के केवल सभी संदेशों को "बंद" कर सकते हैं, एक विशिष्ट संदेश को गलत सकारात्मक के रूप में चिह्नित करने की कोई संभावना नहीं है।

बेशक, बिल्ड से बिल्ड करने के लिए कोई ट्रैकिंग नहीं है। आप केवल संदेशों की कुल संख्या पर ध्यान केंद्रित कर सकते हैं।

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

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

और इसे बंद करने के लिए, यह केवल स्थानीय रूप से काम करता है। जब एक टीम में काम करते हैं, तो बाकी (केवल पाठ की कॉपी-पेस्ट, अलास) के लिए पाई गई समस्याओं को आसानी से और जल्दी से रिपोर्ट करने का कोई तरीका नहीं है, क्योंकि सभी प्रतिभागियों द्वारा इसे चलाने का कोई तरीका नहीं है (जब तक, निश्चित रूप से, प्रत्येक प्रतिभागी के लिए एक अलग लाइसेंस खरीदा जाता है)।

बेशक, पीसी-लिंट और प्लसस हैं।

संदेशों की संख्या को कुछ शर्तों के तहत प्लस माना जा सकता है। इस तथ्य के बावजूद कि अधिकांश संदेश शैली से संबंधित हैं और लगभग कभी भी संभावित समस्या का संकेत नहीं देते हैं, यह पहचानने योग्य है कि लगभग हर संदेश में सामान्य ज्ञान की एक बूंद होती है। और अगर (सैद्धांतिक रूप से) सब कुछ ठीक हो जाता है जिसे पीसी-लिंट ठीक करने की पेशकश करता है, तो कोड स्पष्ट रूप से बेहतर, अधिक समझने योग्य और पठनीय बन जाएगा। लेकिन, जैसा कि इंटरनेट पर किसी ने कहा, "मैं सी में कार्यक्रम करना चाहता हूं, लिंट नहीं!"

"कॉस्मेटिक" टिप्पणी का एक उदाहरण:

यह था:

calib_offset = (int32)(full_offset / full_gain * 100000); 

PC- लिंट यहाँ पढ़ने की अस्पष्टता देखता है: a / b * c - यह है (a / b) * c या a / (b * c)?

तदनुसार, यह बन गया:

 calib_offset = (int32)( (full_offset / full_gain) * 100000); 

मेरी राय में, पठनीयता बढ़ी है!

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

अन्य फायदों के बीच, मैं निम्नलिखित भेद कर सकता हूं:

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

और अंत में - वास्तव में समस्या वाले क्षेत्रों की एक जोड़ी:

यह था:

  switch (SocketID) { case SOCKETID_1: case SOCKETID_2: break; case SOCKETID_3: doSomething(); break; case SOCKETID_4: doSomethingElse(); case SOCKETID_5: doSomethingElseSimilar(); case SOCKETID_6: doAnotherThing(); break; default: return ERR_SERVICE_NOT_SUPPORTED; } 

यह बन गया:

  switch (SocketID) { case SOCKETID_1: case SOCKETID_2: break; case SOCKETID_3: doSomething(); break; case SOCKETID_4: doSomethingElse(); break; case SOCKETID_5: doSomethingElseSimilar(); break; case SOCKETID_6: doAnotherThing(); break; default: return ERR_SERVICE_NOT_SUPPORTED; } 

अगर किसी ने अचानक ध्यान नहीं दिया, तो शब्द ब्रेक दो बार गायब था;

 void main_task(void *p_arg) { int status; // somewhere below… status = memory_init(&memory_config[0], memory_heap, sizeof(memory_heap)); // and later “status” in never used… } 

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

और यह कोड को फिर से उपयोग करने के लिए "ईमानदार" है जैसा कि अप्रयुक्त चर को घोषित किए बिना और परिणाम को स्पष्ट रूप से छोड़ने के बिना।

 void main_task(void *p_arg) { // some code… memory_init(&memory_config[0], memory_heap, sizeof(memory_heap)); // some other code } 

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

और इसके लिए हमें एक स्थिर कोड विश्लेषक की आवश्यकता है जो नियमित रूप से (प्रत्येक बिल्ड के बाद आदर्श रूप से) चलता है, साथ ही आवश्यकता होती है "विश्लेषक से शून्य चेतावनी"।

बेशक, कोई भी विश्लेषक एक सक्षम डेवलपर, कोड की समीक्षा, और अन्य विकास प्रबंधन तकनीकों और विधियों की जगह नहीं ले सकता। हालाँकि, यह निश्चित रूप से उचित उपयोग के साथ पूरी टीम के लिए जीवन आसान बना सकता है!