टीम को हतोत्साहित किए बिना किसी विरासत परियोजना में स्थिर कोड विश्लेषक को कैसे कार्यान्वित करें

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

परिचय

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

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

समस्याएँ

आमतौर पर इसे लॉन्च करना और देखना मुश्किल नहीं है कि एक स्थैतिक विश्लेषक कैसे काम करता है [1]. आपको कोड में दिलचस्प त्रुटियाँ या डरावनी संभावित कमजोरियाँ भी दिखाई दे सकती हैं। आप कुछ ठीक भी कर सकते हैं, लेकिन फिर कई प्रोग्रामर हार मान लेते हैं।

सभी स्थैतिक विश्लेषक गलत सकारात्मक परिणाम उत्पन्न करते हैं। यह स्थैतिक कोड विश्लेषण पद्धति की एक विशेषता है, और इसके बारे में कुछ नहीं किया जा सकता है। सामान्य स्थिति में, यह एक अघुलनशील समस्या है, जैसा कि राइस प्रमेय द्वारा पुष्टि की गई है [2]. मशीन लर्निंग एल्गोरिदम भी मदद नहीं करेगा [3]. यहां तक ​​कि अगर कोई व्यक्ति हमेशा यह नहीं बता सकता कि यह या वह कोड गलत है, तो आपको प्रोग्राम से यह उम्मीद नहीं करनी चाहिए :)।

यदि स्थैतिक विश्लेषक पहले से ही कॉन्फ़िगर किया गया है तो गलत सकारात्मकता कोई समस्या नहीं है:

• अक्षम अप्रासंगिक नियम सेट;
• कुछ अप्रासंगिक निदान अक्षम कर दिए गए हैं;
• यदि हम C या C++ के बारे में बात कर रहे हैं, तो मैक्रोज़ को चिह्नित किया जाता है जिसमें विशिष्ट संरचनाएं होती हैं जो हर जगह जहां ऐसे मैक्रोज़ का उपयोग किया जाता है, वहां बेकार चेतावनियां दिखाई देती हैं;
• स्वयं के फ़ंक्शंस को चिह्नित किया जाता है जो सिस्टम फ़ंक्शंस (अपने स्वयं के एनालॉग) के समान कार्य करते हैं याद रखने योग्य या printf) [4];
• टिप्पणियों का उपयोग करके झूठी सकारात्मकताओं को विशेष रूप से अक्षम कर दिया जाता है;
• और इतने पर.

इस मामले में, हम लगभग 10-15% की कम झूठी सकारात्मक दर की उम्मीद कर सकते हैं [5]. दूसरे शब्दों में, 9 में से 10 विश्लेषक चेतावनियाँ कोड में एक वास्तविक समस्या का संकेत देंगी, या कम से कम "तेज गंध वाला कोड"। सहमत हूँ, यह परिदृश्य अत्यंत सुखद है, और विश्लेषक प्रोग्रामर का सच्चा मित्र है।

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

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

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

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

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

यह संकलक चेतावनियों के समान ही सादृश्य है। यह अकारण नहीं है कि वे संकलक चेतावनियों की संख्या 0 पर रखने की अनुशंसा करते हैं। यदि 1000 चेतावनियाँ हैं, तो 1001 होने पर कोई इस पर ध्यान नहीं देगा, और यह स्पष्ट नहीं है कि इस नवीनतम चेतावनी को कहाँ देखा जाए।

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

तकनीकी ऋण को लागू करना और समाप्त करना

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

सीआई / सीडी

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

• पीवीएस-स्टूडियो बादलों पर जाता है: एज़्योर डेवॉप्स
• पीवीएस-स्टूडियो बादलों पर जाता है: ट्रैविस सीआई
• पीवीएस-स्टूडियो बादलों पर जाता है: गिटलैब सीआई/सीडी
• पीवीएस-स्टूडियो बादलों पर जाता है: सर्कलसीआई

लेकिन आइए कोड विश्लेषण टूल को लागू करने के पहले चरण में बड़ी संख्या में झूठी सकारात्मकता के मुद्दे पर वापस आएं।

मौजूदा तकनीकी ऋण को ठीक करना और नई चेतावनियों से निपटना

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

स्थैतिक विश्लेषण का उपयोग शीघ्रता से शुरू करने के लिए, हमारा सुझाव है कि पीवीएस-स्टूडियो उपयोगकर्ता चेतावनियों के बड़े पैमाने पर दमन के लिए तंत्र का उपयोग करें [6]. सामान्य विचार निम्नलिखित है. उपयोगकर्ता ने विश्लेषक लॉन्च किया और कई चेतावनियाँ प्राप्त कीं। चूँकि एक परियोजना जो कई वर्षों से विकास में है, जीवित है, विकसित हो रही है और पैसा कमा रही है, तो सबसे अधिक संभावना है कि रिपोर्ट में गंभीर दोषों का संकेत देने वाली कई चेतावनियाँ नहीं होंगी। दूसरे शब्दों में, अधिक महंगे तरीकों का उपयोग करके या ग्राहकों की प्रतिक्रिया के कारण महत्वपूर्ण बगों को पहले ही किसी न किसी तरह से ठीक कर दिया गया है। तदनुसार, विश्लेषक वर्तमान में जो कुछ भी पाता है उसे तकनीकी ऋण माना जा सकता है, जिसे तुरंत समाप्त करने का प्रयास करना अव्यावहारिक है।

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

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

तो, एक बड़े पुराने प्रोजेक्ट में विश्लेषक के कार्यान्वयन की पहली समस्या हल हो गई है। अब आइए जानें कि तकनीकी ऋण का क्या करें।

बग फिक्स और रीफैक्टरिंग

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

if (a = b)

अधिकांश C++ कंपाइलर और विश्लेषक ऐसे कोड के बारे में शिकायत करते हैं, क्योंकि इस बात की बहुत अधिक संभावना है कि वे वास्तव में लिखना चाहते थे (ए == बी). लेकिन एक अनकहा समझौता है, और यह आमतौर पर दस्तावेज़ीकरण में नोट किया जाता है, कि यदि अतिरिक्त कोष्ठक हैं, तो यह माना जाता है कि प्रोग्रामर ने जानबूझकर ऐसा कोड लिखा है, और शपथ लेने की कोई आवश्यकता नहीं है। उदाहरण के लिए, डायग्नोस्टिक्स के लिए पीवीएस-स्टूडियो दस्तावेज़ में वी559 (सीडब्ल्यूई-481) इसमें स्पष्ट लिखा है कि निम्नलिखित पंक्ति सही एवं सुरक्षित मानी जायेगी:

if ((a = b))

एक और उदाहरण। क्या यह इस C++ कोड में भूल गया है? तोड़ना या नहीं?

case A:
  foo();
case B:
  bar();
  break;

पीवीएस-स्टूडियो विश्लेषक यहां एक चेतावनी जारी करेगा वी796 (सीडब्ल्यूई-484). यह कोई त्रुटि नहीं हो सकती है, ऐसी स्थिति में आपको विशेषता जोड़कर पार्सर को एक संकेत देना चाहिए [[असफल]] या उदाहरण के लिए __विशेषता__((पतन)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

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

बग फिक्स और रीफैक्टरिंग के अलावा, आप विशेष रूप से स्पष्ट रूप से गलत विश्लेषक चेतावनियों को दबा सकते हैं। कुछ अप्रासंगिक निदान अक्षम किए जा सकते हैं. उदाहरण के लिए, कोई सोचता है कि चेतावनियाँ व्यर्थ हैं V550 फ्लोट/डबल मानों की तुलना के बारे में। और कुछ लोग उन्हें महत्वपूर्ण और अध्ययन के योग्य मानते हैं [7]. कौन सी चेतावनियाँ प्रासंगिक मानी जाती हैं और कौन सी नहीं, यह निर्णय लेना विकास टीम पर निर्भर है।

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

इसके अलावा, यदि कोई कठिनाई आती है तो हम हमेशा अपने ग्राहकों को पीवीएस-स्टूडियो स्थापित करने में मदद करते हैं। इसके अलावा, ऐसे मामले भी थे जब हमने स्वयं झूठी चेतावनियों को हटा दिया और त्रुटियों को ठीक किया [8]. बस मामले में, मैंने यह उल्लेख करने का निर्णय लिया कि विस्तारित सहयोग के लिए यह विकल्प भी संभव है :)।

शाफ़्ट विधि

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

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

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

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

लेख के लेखक की इस विषय पर एक रिपोर्ट भी है: "सतत स्थैतिक विश्लेषण".

निष्कर्ष

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

इस बारे में अन्य विशिष्ट संदेह हैं कि क्या स्थैतिक विश्लेषण वास्तव में सुविधाजनक और उपयोगी हो सकता है। मैंने "विकास प्रक्रिया में पीवीएस-स्टूडियो स्टैटिक कोड विश्लेषक को पेश करने के कारण" प्रकाशन में इनमें से अधिकांश संदेहों को दूर करने का प्रयास किया [9].

आपका ध्यान देने के लिए धन्यवाद और आइए डाउनलोड और पीवीएस-स्टूडियो विश्लेषक आज़माएँ।

अतिरिक्त लिंक

1. एंड्री कार्पोव. मैं पीवीएस-स्टूडियो विश्लेषक द्वारा सी और सी++ कोड के लिए तैयार की जाने वाली दिलचस्प चेतावनियों को तुरंत कैसे देख सकता हूं?
2. विकिपीडिया. चावल का प्रमेय.
3. एंड्री कारपोव, विक्टोरिया खानियेवा। प्रोग्राम स्रोत कोड के स्थैतिक विश्लेषण में मशीन लर्निंग का उपयोग करना.
4. पीवीएस-स्टूडियो। दस्तावेज़ीकरण. अतिरिक्त निदान सेटिंग्स.
5. एंड्री कार्पोव. ईएफएल कोर लाइब्रेरीज़ के उदाहरण का उपयोग करके पीवीएस-स्टूडियो विश्लेषक की विशेषताएं, 10-15% झूठी सकारात्मकता.
6. पीवीएस-स्टूडियो। दस्तावेज़ीकरण. विश्लेषक संदेशों का बड़े पैमाने पर दमन.
7. इवान एंड्रियाशिन। हमने एक्स-रे एंडोवास्कुलर सर्जरी के एक शैक्षिक सिम्युलेटर की हमारी परियोजना पर स्थैतिक विश्लेषण का परीक्षण कैसे किया.
8. पावेल एरेमीव, शिवतोस्लाव रज़मिस्लोव। पीवीएस-स्टूडियो टीम ने अनरियल इंजन कोड में कैसे सुधार किया.
9. एंड्री कार्पोव. विकास प्रक्रिया में स्थैतिक कोड विश्लेषक पीवीएस-स्टूडियो को पेश करने के कारण.

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

स्रोत: www.habr.com