टोलीलाई डिमोटिभ नगरी विरासत परियोजनामा ​​स्थिर कोड विश्लेषक कसरी लागू गर्ने

यो एक स्थिर कोड विश्लेषक प्रयास गर्न सजिलो छ। तर यसलाई कार्यान्वयन गर्न, विशेष गरी ठूलो पुरानो परियोजनाको विकासमा, सीप चाहिन्छ। यदि गलत तरिकाले गरियो भने, विश्लेषकले काम थप्न सक्छ, विकासलाई ढिलो गर्न सक्छ, र टोलीलाई घटाउन सक्छ। विकास प्रक्रियामा स्थैतिक विश्लेषणको एकीकरणलाई कसरी ठीकसँग पहुँच गर्ने र यसलाई CI/CD को भागको रूपमा प्रयोग गर्न सुरु गर्ने बारे संक्षिप्त रूपमा कुरा गरौं।

परिचय

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

हाम्रो PVS-Studio टोलीले यस विषयमा आफ्नो दृष्टिकोण प्रस्तुत गर्दछ। एक स्थिर कोड विश्लेषक लागू गर्ने समस्या पहिलो स्थानमा कसरी उत्पन्न हुन्छ, यस समस्यालाई कसरी पार गर्ने, र कसरी पीडारहित रूपमा प्राविधिक ऋणलाई बिस्तारै हटाउने भनेर हेरौं।

मुद्दाहरू

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

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

यदि स्थिर विश्लेषक पहिले नै कन्फिगर गरिएको छ भने झूटा सकारात्मकहरू समस्या होइनन्:

• असक्षम अप्रासंगिक नियम सेट;
• केहि अप्रासंगिक निदान असक्षम गरिएको छ;
• यदि हामी C वा C++ को बारेमा कुरा गर्दैछौं भने, त्यस्ता म्याक्रोहरू प्रयोग गरिएका प्रत्येक ठाउँमा बेकार चेतावनीहरू देखा पर्ने विशिष्ट संरचनाहरू समावेश गर्ने म्याक्रोहरू चिन्ह लगाइन्छ;
• आफ्नै प्रकार्यहरू चिन्ह लगाइन्छ जसले प्रणाली प्रकार्यहरू जस्तै कार्यहरू गर्दछ (यसको आफ्नै एनालग मेम्पी वा printf) [4];
• गलत सकारात्मक टिप्पणीहरू प्रयोग गरेर विशेष रूपमा अक्षम गरिएको छ;
• र त्यसमा।

यस अवस्थामा, हामी लगभग 10-15% को कम गलत सकारात्मक दरको आशा गर्न सक्छौं।5]। अन्य शब्दहरूमा, 9 विश्लेषक चेतावनीहरू मध्ये 10 कोडमा वास्तविक समस्या, वा कम्तिमा "बलियो गन्ध कोड" लाई संकेत गर्दछ। सहमत हुनुहोस्, यो परिदृश्य अत्यन्तै सुखद छ, र विश्लेषक प्रोग्रामरको वास्तविक मित्र हो।

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

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

निस्सन्देह, सानातिना गल्तीहरू पनि गल्तीहरू हुन्। र कहिलेकाहीँ गल्तीले वास्तविक जोखिम लुकाउन सक्छ। जे होस्, सबै कुरा त्याग्नु र दिन/हप्ताहरू बिताउनु दोषहरूसँग व्यवहार गर्ने जुन बल्ल आफैंमा प्रकट हुन्छ एक शंकास्पद विचार जस्तो देखिन्छ।

प्रोग्रामरहरू हेर्छन्, हेर्छन्, पुरानो कार्य कोडको बारेमा यी सबै चेतावनीहरू हेर्नुहोस्... र तिनीहरू सोच्छन्: हामी स्थिर विश्लेषण बिना गर्न सक्छौं। केही नयाँ उपयोगी कार्यक्षमता लेखौं।

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

यो कम्पाइलर चेतावनी संग समान समानता हो। यो बिना कारण होइन कि तिनीहरूले 0 मा कम्पाइलर चेतावनीहरूको संख्या राख्न सिफारिस गर्छन्। यदि त्यहाँ 1000 चेतावनीहरू छन् भने, जब त्यहाँ 1001 छन्, कसैले यसलाई ध्यान दिनेछैन, र यो नयाँ चेतावनी कहाँ खोज्ने स्पष्ट छैन।

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

प्राविधिक ऋण कार्यान्वयन र हटाउने

वास्तवमा, ठुलो पुरानो परियोजनामा ​​पनि स्थिर विश्लेषणको परिचय दिन गाह्रो वा डरलाग्दो कुरा छैन।

CI / CD

यसबाहेक, विश्लेषक तुरुन्तै निरन्तर विकास प्रक्रियाको हिस्सा बनाउन सकिन्छ। उदाहरणका लागि, PVS-स्टुडियो वितरणले तपाईंलाई आवश्यक पर्ने ढाँचामा रिपोर्ट सहज रूपमा हेर्नको लागि उपयोगिताहरू समावेश गर्दछ, र कोडको समस्याग्रस्त खण्डहरू लेख्ने विकासकर्ताहरूलाई सूचनाहरू। CI/CD प्रणालीबाट PVS-Studio लन्च गर्न थप रुचि राख्नेहरूका लागि, म सुझाव दिन्छु कि तपाईं आफैलाई सम्बन्धितसँग परिचित हुनुहोस्। खण्ड दस्तावेज र लेख को एक श्रृंखला:

• PVS-स्टुडियो क्लाउडहरूमा जान्छ: Azure Devops
• PVS-स्टुडियो क्लाउडहरूमा जान्छ: ट्राभिस CI
• PVS-स्टुडियो क्लाउडहरूमा जान्छ: GitLab CI/CD
• PVS-स्टुडियो क्लाउडमा जान्छ: CircleCI

तर कोड विश्लेषण उपकरणहरू लागू गर्ने पहिलो चरणहरूमा ठूलो संख्यामा झूटा सकारात्मकहरूको मुद्दामा फर्कौं।

विद्यमान प्राविधिक ऋण फिक्स गर्दै र नयाँ चेतावनीहरूसँग व्यवहार गर्दै

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

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

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

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

त्यसैले, एक ठूलो पुरानो परियोजना मा विश्लेषक को कार्यान्वयन संग पहिलो समस्या हल भएको छ। अब प्राविधिक ऋणको साथ के गर्ने भनेर पत्ता लगाउनुहोस्।

बग समाधान र रिफ्याक्टरिङ

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

if (a = b)

धेरैजसो C++ कम्पाइलर र विश्लेषकहरूले त्यस्ता कोडको बारेमा गुनासो गर्छन्, किनकि उनीहरूले वास्तवमा लेख्न चाहेको उच्च सम्भावना हुन्छ (a == b)। तर त्यहाँ एक अस्पष्ट सम्झौता छ, र यो सामान्यतया कागजातमा उल्लेख गरिएको छ, यदि त्यहाँ अतिरिक्त कोष्ठकहरू छन् भने, यो मानिन्छ कि प्रोग्रामरले जानाजानी यस्तो कोड लेख्यो, र कसम खानु आवश्यक छैन। उदाहरण को लागी, निदान को लागी PVS-स्टुडियो दस्तावेज मा V559 (CWE-481) यो स्पष्ट रूपमा लेखिएको छ कि निम्न रेखा सही र सुरक्षित मानिनेछ:

if ((a = b))

अर्को उदाहरण। के यो C++ कोडमा बिर्सिएको छ? ब्रेक वा छैन?

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

PVS-स्टुडियो विश्लेषकले यहाँ चेतावनी जारी गर्नेछ V796 (CWE-484)। यो त्रुटि नहुन सक्छ, जसमा तपाईले पार्सरलाई विशेषता थपेर संकेत दिनु पर्छ। [[पतन]] वा उदाहरणका लागि __विशेषता__((फलथ्रु)):

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

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

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

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

साथै, हामी सधैं हाम्रा ग्राहकहरूलाई PVS-Studio सेटअप गर्न मद्दत गर्छौं यदि कुनै कठिनाइहरू उत्पन्न हुन्छन्। यसबाहेक, त्यहाँ घटनाहरू थिए जब हामीले आफैंले गलत चेतावनीहरू हटायौं र त्रुटिहरू सुधार्यौं।8]। मात्र के अवस्थामा, मैले विस्तारित सहयोगको लागि यो विकल्प पनि सम्भव छ भनेर उल्लेख गर्ने निर्णय गरे :)।

र्याचेट विधि

स्थिर विश्लेषक चेतावनी हटाएर कोडको गुणस्तर विस्तारै सुधार गर्न अर्को रोचक दृष्टिकोण छ। तलको रेखा भनेको चेतावनीहरूको संख्या मात्र कम हुन सक्छ।

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

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

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

लेखको लेखकको पनि यस विषयमा रिपोर्ट छ: "निरन्तर स्थिर विश्लेषण".

निष्कर्षमा

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

स्थिर विश्लेषण साँच्चै सुविधाजनक र उपयोगी हुन सक्छ कि छैन भन्ने बारे अन्य सामान्य शंकाहरू छन्। मैले "PVS-Studio स्थिर कोड विश्लेषकलाई विकास प्रक्रियामा परिचय गराउने कारणहरू" प्रकाशनमा यी धेरैजसो शंकाहरू हटाउने प्रयास गरें9].

तपाईंको ध्यान र आउनुहोस् को लागी धन्यवाद скачать र PVS-स्टुडियो विश्लेषक प्रयास गर्नुहोस्।

अतिरिक्त लिङ्कहरू

1. Andrey Karpov। PVS-स्टुडियो विश्लेषकले C र C++ कोडको लागि उत्पादन गर्ने रोचक चेतावनीहरू कसरी म चाँडै हेर्न सक्छु?
2. विकिपीडिया। चामलको प्रमेय.
3. आन्द्रे कार्पोभ, भिक्टोरिया खानिएवा। कार्यक्रम स्रोत कोडको स्थिर विश्लेषणमा मेसिन लर्निङ प्रयोग गर्दै.
4. PVS-स्टुडियो। कागजात। अतिरिक्त निदान सेटिङहरू.
5. Andrey Karpov। EFL कोर पुस्तकालयहरूको उदाहरण प्रयोग गरेर PVS-स्टुडियो विश्लेषकको विशेषताहरू, 10-15% गलत सकारात्मक.
6. PVS-स्टुडियो। कागजात। विश्लेषक सन्देशहरूको सामूहिक दमन.
7. इवान एन्ड्रियासिन। हामीले कसरी एक्स-रे एन्डोभास्कुलर सर्जरीको शैक्षिक सिमुलेटरको हाम्रो परियोजनामा ​​स्थिर विश्लेषणको परीक्षण गर्यौं भन्ने बारे।.
8. पावेल Eremeev, Svyatoslav Razmyslov। कसरी PVS-स्टुडियो टोलीले अवास्तविक इन्जिन कोड सुधार गर्यो.
9. Andrey Karpov। विकास प्रक्रियामा स्थिर कोड विश्लेषक PVS-स्टुडियो परिचय गराउने कारणहरू.

यदि तपाइँ यो लेख अंग्रेजी बोल्ने दर्शकहरूसँग साझा गर्न चाहनुहुन्छ भने, कृपया अनुवाद लिङ्क प्रयोग गर्नुहोस्: Andrey Karpov। विरासत परियोजनामा ​​एक स्थिर कोड विश्लेषक कसरी परिचय गर्ने र टोलीलाई निरुत्साहित नगर्ने.

स्रोत: www.habr.com